Make cargo-credential-gnome-secret built-in as cargo:libsecret
We previously couldn't have cargo-credential-gnome-secret built into Cargo because of its build-time dependency on `libsecret`. However, this limitation has now been lifted by #12518.
Adds a new built-in credential provider `cargo:libsecret`.
Adds `ISC` as an allowed license for `libloading`.
* `rustc` already uses `libloading`
* ISC license is very similar to MIT
Renames the crate from `cargo-credential-gnome-secret` to `cargo-credential-libsecret` and changes the crate structure to more closely match `wincred` and `macos-keychain`.
login: allow passing additional args to provider
As part of moving asymmetric token support to a credential provider in #12334, support for passing `--key-subject` to `cargo login` was removed.
This change allows passing additional arguments to credential providers when running `cargo login`. For example:
`cargo login -- --key-subject foo`.
The asymmetric token provider (`cargo:paseto`) is updated to take advantage of this and re-enables setting `--key-subject` from `cargo login`.
r? `@Eh2406`
cc #8933
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.
credential-providers: make 1password no longer built-in
Since 1password is just one of many potential CLI-based credential providers, it makes more sense for it to be installable as a plugin rather than built-in to Cargo.
This means that `cargo:1password` will no longer work as a credential provider.
The replacement would be `cargo install cargo-credential-1password` and using `cargo-credential-1password` instead.
r? `@ehuss`
credential: rename cargo:basic to cargo:token-from-stdout
Multiple people have said that the name of the `cargo:basic` credential provider is confusing, since it's not doing HTTP Basic authentication.
Rename `cargo:basic` to `cargo:token-from-stdout`, which more accurately describes what it does.
versions and paths of a workspace members between the original and
a checked-out workspace are different, and shouldn't be included in
hash keys when querying packages.
The `github.sha` is a merge commit with the parents of latest master
and the head of the pr. Trying to diff the changes from that merge
SHA to base will show all changes that have been made in-between.
And that doesn't seem about right.
We switch to `github.event.pull_request.head.sha` if there is a pr.
See: https://rust-lang.zulipchat.com/#narrow/stream/246057-t-cargo/topic/version-bump.20CI.20failing
Crate checksum lookup query should match on semver build metadata
Since crates.io allows crate versions to differ only by build metadata, a query using `OptVersionReq::exact` + `next()` can return nondeterministic results.
This change fixes the issue by adding an additional `filter` that ensures the version is equal (including build metadata).
It still feels somewhat wrong that a query using `exact` can match multiple crates, so an alternative fix would be to add a new variant of `OptVersionReq` that also matched on build metadata.
Fixes#11412
