Enable cargo:libsecret on all Unix platforms except macOS and mobile

[quinnjr]

What does this PR try to resolve?

The cargo:libsecret built-in credential provider is currently gated on target_os = "linux", with every other platform receiving an UnsupportedCredential stub. That gate is an artificial restriction rather than a technical one: libsecret and Secret Service implementations (gnome-keyring, KWallet) are packaged on FreeBSD, OpenBSD, and NetBSD, the provider loads libsecret-1.so.0 dynamically at runtime via libloading (which supports these platforms), and no code inside the provider is Linux-specific. As a result, BSD users have no built-in secure token storage option at all.

This PR widens the cfg gate at all five sites (three in cargo-credential-libsecret, two in src/cargo/util/auth/mod.rs) to:

all(unix, not(any(target_os = "macos", target_os = "ios", target_os = "tvos", target_os = "watchos", target_os = "visionos", target_os = "android")))

macOS keeps its OS-specific cargo:macos-keychain provider, and the mobile Unix targets are excluded since libsecret does not exist there. Platform availability is now documented in registry-authentication.md and the crate README.

This is pre-work for the in-progress RFC 3981: Store registry tokens in the OS credential store by default (rust-lang/rfcs#3981). That RFC proposes flipping secure token storage from opt-in to the default and calls out the BSD gap in Cargo's built-in providers as an adoption blocker; this change closes that gap independently of the RFC's outcome. Since cargo:libsecret is never in the default provider list, nothing changes for users who haven't explicitly configured it.

How to test and review this PR?

The diff is a mechanical cfg widening plus docs — the Linux behavior is unchanged (the new predicate is true exactly where the old one was, plus the newly enabled targets).

Tested on a FreeBSD 15.1-RELEASE amd64 VM with libsecret and gnome-keyring over a D-Bus session bus, using a small harness that drives the Credential trait implementation directly:

• LibSecretCredential::new() loads libsecret-1.so.0 via dlopen
• Login stores the token in the Secret Service
• Get retrieves a matching token
• Logout removes it, and a subsequent Get correctly returns Error::NotFound

On Linux (x86_64-unknown-linux-gnu): cargo check -p cargo, cargo check -p cargo-credential-libsecret, and cargo fmt --check pass.

One reviewer question worth settling: on the newly enabled platforms (as on Linux today), a libsecret load failure in get_credential_libsecret() propagates out of credential_action rather than falling through to the next provider in a configured list, unlike the UrlNotSupported the stub used to return at perform() time. This is pre-existing chain semantics extended to more platforms — happy to adjust if fall-through on construction failure is preferred.

🤖 Generated with Claude Code

[rustbot]

Thanks for the pull request, and welcome! The Rust Project is excited to review your changes, and you should hear from @weihanglo (or someone else) some time within the next two weeks.

Please see the contribution instructions for more information. Namely, in order to ensure the minimum review times lag, PR authors and assigned reviewers should ensure that the review label (S-waiting-on-review and S-waiting-on-author) stays updated, invoking these commands when appropriate:

• @rustbot author: the review is finished, PR author should check the comments and take action accordingly
• @rustbot review: the author is ready for a review, this PR will be queued again in the reviewer's queue

Why was this reviewer chosen?

The reviewer was selected based on:

• Owners of files modified in this PR: @ehuss, @epage, @weihanglo
• @ehuss, @epage, @weihanglo expanded to ehuss, epage, weihanglo
• Random selection from ehuss, epage, weihanglo

[weihanglo]

I don't know how to test this on BSD, and I have no machine running on BDS. Do you have any guide and step to follow so I can at least make sure it work?

BTW, this seems reasonable separately from the RFC.

View changes since the review

[quinnjr]

https://gist.github.com/quinnjr/f9d0bea41b21c61dbed373911b93ba71

[weihanglo]

Thanks. I ends up adapting your scripts with qemu (which I used to be familiar with). And it worked!

[quinnjr]

@weihanglo would it be reasonable to add a CI check for BSD compatibility in this PR or leave it as something for later?

[weihanglo]

@weihanglo would it be reasonable to add a CI check for BSD compatibility in this PR or leave it as something for later?

That should be in a separate PR. It would be great if anyone has resources to help do that. BSD family platforms are mostly tier 2 with host tools or tier 3. We haven't done anything like that in Cargo's CI. Personally I'd like to see more CI validation for more platforms.

Feel free to cut an issue first and contribute to that :)

[rustbot]

This PR was rebased onto a different master commit. Here's a range-diff highlighting what actually changed.

Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers.

[quinnjr]

@weihanglo Now that the branch is rebased on latest master and conflicts are resolved — do you need any help setting up or running the verification Gist I shared (https://gist.github.com/quinnjr/f9d0bea41b21c61dbed373911b93ba71)? It spins up a headless FreeBSD VM in VirtualBox and verifies the cargo:libsecret provider end-to-end. Happy to walk through it or adapt the scripts to your environment if that's useful for review.

[weihanglo]

Thanks for the contribution!

@arlosi any thoughts? I think this is a good enhancement expanding the support to more platforms.

[epage]

This changes the behavior for cargo:libsecret in a way that could break people. If they have cargo:libsecret set today in a config file synchronized between machines, it will now try to load that credential provider and fail. We likely need something like #13558 first.

[weihanglo]

#17197 (comment)

Good point. Blocked this on that.

View changes since this review

[rustbot]

Reminder, once the PR becomes ready for a review, use @rustbot ready.