Clarify fingerprint log messages
I had to look up the source to figure out which side was the old value for a RUSTFLAGS fingerprint mismatch.
Making the logs a bit more explicit about which value is old and new would've helped me.
Stabilize RUSTC_WORKSPACE_WRAPPER
Stabilizing this environment variable would allow Clippy to fix a long-standing usability problem, [clippy#4612](https://github.com/rust-lang/rust-clippy/issues/4612).
It's also the last step towards stabilizing the `--fix` command-line argument in Clippy, that allows applying suggestions automatically when the lint supports it.
Closes#8143
r? `@ehuss`
Make cargo metadata and tree respect target
Previously, the `metadata` and `tree` subcommands would download
dependencies for all targets, regardless of whether those targets were
actually enabled. This PR updates them so that they only download the
same dependencies that building would do with the requested target(s).
`cargo metadata` still includes all targets by default; you can only opt
_out_ using `--filter-platform`. Ideally it should use `--target` the
same way `tree` does, but it's too late to change that now.
Fixes#8981.
With debug HTTP mode log curl's version
This will hopefully help any future reports where we're trying to
figure out what's going on with possible different versions of the
`curl` library.
Previously, the `metadata` and `tree` subcommands would download
dependencies for all targets, regardless of whether those targets were
actually enabled. This PR updates them so that they only download the
same dependencies that building would do with the requested target(s).
`cargo metadata` still includes all targets by default; you can only opt
_out_ using `--filter-platform`. Ideally it should use `--target` the
same way `tree` does, but it's too late to change that now.
Fixes#8981.
Reject ambiguous git dependency declaration.
This rejects a git dependency that specifies more than one of `branch`, `tag`, or `rev`. Cargo does not handle this case very well, and this warning has been in place for 4 years (since #2940).
Fixes#7841
Clarify FAQ entry wording about lockfiles
I received a report that this FAQ entry (and in particular the wording
"across whatever machine") generated some confusion. Reword the FAQ
entry for clarity.
I received a report that this FAQ entry (and in particular the wording
"across whatever machine") generated some confusion. Reword the FAQ
entry for clarity.
Check if rerun-if-changed points to a directory.
This changes it so that if a build script emits `cargo:rerun-if-changed` pointing to a directory, then Cargo will scan the entire directory for changes (instead of just looking at the mtime of the directory itself). I think this is more useful, as otherwise build scripts have to recreate this logic.
I've tried to make it semi-intelligent in the face of symbolic links. It checks the mtime of the link and its target, and follows the link if it points to a directory.
There are a few other edge cases. For example, if it doesn't have permission for a directory, it will skip it. I think this is relatively reasonable, though it's hard to say for sure.
Implement external credential process. (RFC 2730)
This adds a config setting for an external process to run to fetch the token for a registry. See `unstable.md` for more details.
As part of this, it adds a new `logout` command. This is currently gated on nightly with the appropriate `-Z` flag.
I have included four sample wrappers that integrate with the macOS Keychain, Windows Credential Manager, GNOME libsecret, and 1password. I'm not sure if we'll ultimately ship these, but I would like to. Primarily this provided a proof-of-concept to see if the design works.
**Patch Walkthrough**
This is a brief overview of the changes:
- Adds the `logout` command. With `cargo logout -Z unstable-options`, this allows removing the `token` from `.cargo/credentials`. With `cargo logout -Z credential-process`, this launches the process with the `erase` argument to remove the token from storage.
- Credential-process handling is in the `ops/registry/auth.rs` module. I think it is pretty straightforward, it just launches the process with the appropriate store/get/erase argument.
- `ops::registry::registry()` now returns the `RegistryConfig` to make it easier to pass the config information around.
- `crates/credential/cargo-credential` is a helper crate for writing credential processes.
- A special shorthand of the `cargo:` prefix for a credential process will launch the named process from the `libexec` directory in the sysroot (or, more specifically, the `libexec` directory next to the `cargo` process). For example `credential-process = "cargo:macos-keychain"`. My intent is to bundle these in the pre-built rust-lang distributions, and this should "just work" when used with rustup. I'm not sure how that will work with other Rust distributions, but I'm guessing they can figure it out. This should make it much easier for users to get started, but does add some integration complexity.
**Questions**
- I'm on the fence about the name `credential-process` vs `credentials-process`, which sounds more natural? (Or something else?)
- I'm uneasy about the behavior when both `token` and `credential-process` is specified (see `warn_both_token_and_process` test). Currently it issues a warning and uses `token`. Does that make sense? What about the case where you have `registries.foo.token` for a specific registry, but then have a general `registry.credential-process` for the default (it currently warns and uses the token, maybe it should not warn?)?
- I am still pretty uneasy with writing FFI wrappers, so maybe those could get a little extra scrutiny? They seem to work, but I have not extensively tested them (I tried login, publish, and logout). I have not previously used these APIs, so I am not familiar with them.
- Testing the wrappers I think will be quite difficult, because some require TTY interaction (and 1password requires an online account). Or, for example in the macOS case, it has GUI dialog box where I can use my fingerprint scanner. Right now, I just build them in CI to make sure they compile.
- 1password is a little weird in that it passes the token on the command-line, which is not very secure on some systems (other processes can see these sometimes). The only alternative I can think of is to not support `cargo login` and require the user to manually enter the token in the 1password GUI. I don't think the concern is too large (1password themselves seem to think it is acceptable). Should this be OK?
- I'm a little uneasy with the design of `cargo login`, where it passes the token in stdin. If the wrapper requires stdin for user interaction (such as entering a password to unlock), this is quite awkward. There is a hack in the 1password example that demonstrates using `/dev/tty` and `CONIN$`, which *seems* to work, but I'm worried is fragile. I'm not very comfortable passing the token in environment variables, because those can be visible to other processes (like CLI args), but in some situations that shouldn't be too risky. Another option is to use a separate file descriptor/handle to pass the token in. Implementing that in Rust in a cross-platform way is not terribly easy, so I wanted to open this up for discussion first.
Fix the unit dependency graph with dev-dependency `links`
This commit fixes#8966 by updating the unit generation logic to avoid
generating an erroneous circular dependency between the execution of two
build scripts. This has been present for Cargo in a long time since #5651
(an accidental regression), but the situation appears rare enough that
we didn't get to it until now!
Closes#8966
This commit fixes#8966 by updating the unit generation logic to avoid
generating an erroneous circular dependency between the execution of two
build scripts. This has been present for Cargo in a long time since #5651
(an accidental regression), but the situation appears rare enough that
we didn't get to it until now!
Closes#8966
Change it so that if both are specified, it is an error just to be safer
for now.
If token is specified for a registry, ignore the global
credential-process.
I'm still uncertain if this is the best behavior, but I think we can
tweak it later if needed.
