The library name `libsecret-1.so` is only found in `-dev` or `-devel`
packages on many distros, and it's usually only a symlink. For example,
this is what I have on Fedora:
/usr/lib64/libsecret-1.so -> libsecret-1.so.0
/usr/lib64/libsecret-1.so.0 -> libsecret-1.so.0.0.0
/usr/lib64/libsecret-1.so.0.0.0
$ rpm -qf /usr/lib64/libsecret*
libsecret-devel-0.21.4-2.fc40.x86_64
libsecret-0.21.4-2.fc40.x86_64
libsecret-0.21.4-2.fc40.x86_64
The middle `libsecret-1.so.0` filename matches the actual `SONAME` in
the library, which you can see with `readelf -d`, and this is what
programs built directly against this library will use. It's a better
choice for dynamic loaders too, so devel packages aren't needed.
We likely don't want to release these packages every 6 months just for
an MSRV bump.
By moving the MSRV out of the package, `cargo bump-check` will ignore
the MSRV bump.
Inspired by #13266
This will require a version bump every release but over-releasing these
packages is likely a lot better than over-releasing the N-3 packages,
which we won't have to do anymore after this.
My hope is the `auto` value will be approved and stabilized and then we
won't have to over-release anymore.
Like PR 12352 but for homepage and repository
Versions for
* `cargo-credential-1password`
* `cargo-util-schemas`
* `home`
are bumped along with the change.
e58b84d changed the shape of response of cargo credential protocol trait,
so credential plugins crates effectively depend on `cargo-credential@0.4.0`.
However, `cargo@0.74.0` still depends on`cargo-credential@0.3.0`.
They must depends on the same major version of `cargo-credential`
otherwise incompatible.
This PR
* bumps the version to `cargo-credential-wincred@0.4.2`
* bumps the version to `cargo-credential-macos-keychain@0.4.2`
* bumps the version to `cargo-credential-li@0.4.2`
See rust-lang#13004 for more.
cargo-credential-1password: Add missing `--account` argument to `op signin` command
### What does this PR try to resolve?
Without this the account chooser is shown by the `op signin` command, even though the user has already specified an account via the `--account` command line argument to the `cargo-credential-1password` CLI.
Note that the `--vault` in this case does not need to be forwarded to `op`, since it is irrelevant for the `op signin` command.
### How should we test and review this PR?
- Have a 1password installation with multiple accounts
- Use `global-credential-providers = ["cargo-credential-1password --account my.1password.com"]` in the cargo config file
- Run e.g. `cargo publish`
- Notice how you are seeing an account switcher even though `--account` was used
- Apply this patch and notice that the account switcher is no longer there and the correct account is selected automatically
### Additional information
see https://rust-lang.zulipchat.com/#narrow/stream/246057-t-cargo/topic/1password.20credentials.20provider
Without this the account chooser is shown by the `op signin` command, even though the user has already specified an account via the `--account` command line argument to the `cargo-credential-1password` CLI.
Note that the `--vault` in this case does not need to be forwarded to `op`, since it is irrelevant for the `op signin` command.
cargo-credential-gnome-secret: dynamically load libsecret
Building `cargo-credential-gnome-secret` currently requires the `libsecret` development libraries to be installed and findable via `pkg-config`. This is often an extra step for users and complicates CI builds.
This loads the required functions from `libsecret` dynamically using `libloading` which uses `dlopen` internally.
Closes#12503
Testing this requires manually installing the credential provider on a system with libsecret set up. I tested it on Arch Linux.
