Feature request: Disabling keyutils (and only using secret-service) on Linux #153
Comments
|
My understanding is that keyutils is part of the kernel on Linux and so there are no additional dependencies included by the keyutils credential store. (Perhaps @landhb knows better?) Are you asking for a way of compiling this crate so that the keyutils credential store is not even included in the build? |
keyring depends on the linux-keyutils crate on Linux to interact with the kernel functionality. That in turn depends an old version of bitflags (the only crate in my dependency tree pulling in bitflags 1.x, causing duplication of that dependency). Which in turn pulls in more things. And so on.
Yes exactly. This will help with compile times and size of build trees (I'm running into the 10 GB limit on caches in GitHub CI due to the large build tree in combination with the large number of cross compiled architectures I'm supporting). |
Oh, right, duh! That will teach me not to look at my own Cargo.toml file before answering 🤦. This is a good suggestion, and easy. I'll implement it right away. |
|
Actually this issue makes me realize that the way the features have been defined are all wrong. Even the platform dependencies should be controlled by features not by platform, in case users want to be using (for example) an internet-based store and don't want to pay the cost of the platform dependencies. If no platform keystores are available, the mock keystore should be used as the default. |
This fixes hwchen#153 by making all platform dependencies be features and including them as default features, so now you can suppress building all platform dependencies by suppressing default features. This also fixes hwchen#148 by having the code check to see if there is platform support and, if not, using the mock keystore as the default. While this change is not fully backward compatible for people who were suppressing default features on macOS, iOS, Win, or FreeBSD, doing so was undefined behavior on those platforms and so changing it does not break the semantics of the API.
This fixes hwchen#153 by making all platform dependencies be features and including them as default features, so now you can suppress building all platform dependencies by suppressing default features. This also fixes hwchen#148 by having the code check to see if there is platform support and, if not, using the mock keystore as the default. While this change is not fully backward compatible for people who were suppressing default features on macOS, iOS, Win, or FreeBSD, doing so was undefined behavior on those platforms and so changing it does not break the semantics of the API.
|
Release v2.2.0 fixes this issue. You can now do |
I'm trying to put my dependency tree on a diet and discovered that keyring seems to always pull in support for keyutils on Linux, even though I only ever use DBUS secret service (since I'm writing an interactive desktop program).
I don't see a way in your Cargo.toml to disable this. Would it be possible to make it a feature (enabled by default for backward compatibility of course)? Then those who don't need it can pull in keyring with no-default-features and just the feature
linux-secret-serviceThe text was updated successfully, but these errors were encountered: