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
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.
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.
Fixes#8783 , cargo new fails without a author name or email
If user can not be obtained from git or env variables $USER, new command defaults to empty author in generated Cargo.toml
Could not edit old PR(#8910 8783) as the original clone was deleted.
Fix test escaping __CARGO_TEST_ROOT
#8886 added a test which unsets `__CARGO_TEST_ROOT`, but that environment variable is there for a reason. This causes problems as it causes that test to load the `.cargo/config` from the real home directory, which if it contains a `[cargo-new]` section, causes the test to fail.
The fix here is to change `find_tests_git_config` so that it behaves more like the real git config loader, but avoids escaping the test sandbox. There are some subtle issues here, like #7469, which I believe should still work correctly.
Add "--workspace" to update command
My `--bin` project has CI which updates the version number in `Cargo.toml`, which it then commits. However, this means that any further cargo command (`build`, `test`, etc) will update the existing `Cargo.lock` file (updating the root version), causing some frustration for users. Furthermore, it breaks the `publish` command, which requires the repo to be current.
I've added a `sync-lockfile` command to simply update the root version in the `Cargo.lock` file to match the `Cargo.toml` in the same way that simple commands like `fetch` do. If no `Cargo.lock` file is present, and new one is generated based on the index.
This is a demo PR for Pre-RFC conversation at https://internals.rust-lang.org/t/pre-rfc-cargo-command-to-just-sync-lockfile/13119, but may become a real PR if it gets approval.
Start searching git config at new path
This lets `cargo new` follow `includeIf` blocks inside .gitignore.
Fixes#8882
I am not sure if removing the `__CARGO_TEST_ROOT` environment variable has any bad side effects. My quick grep of the repository didn't highlight anything in particular.
Publish target's "doc" setting when emitting metadata
Prior to this commit `cargo metadata` would not emit the value of a
target's "doc" setting, used by `cargo doc` to determine whether
documentation should be generated. However, this information is useful
for machine programs interested in such targets, and the information is
already made available on the internal representation of a target, so
this commit just exposes that during target serialization for emit.
cf https://github.com/deadlinks/cargo-deadlinks/issues/99
Finish implementation of `-Zextra-link-arg`.
This is a continuation of https://github.com/rust-lang/cargo/pull/7811, which adds tests and a warning if the `-Zextra-link-arg` flag is not specified. Also moved the documentation into `unstable.md`.
Reproducible crate builds
This series introduces reproducible crate builds. Since crates are essentially gzipped tar archives, we canonicalize the fields such that they don't contain extraneous and potentially privacy-leaking data such as user and group names and IDs, device major and minor, and system timestamps. Outside of the timestamps, the user probably did not intend to share information about their user or system, so this also improves developer privacy somewhat.
The individual commit messages include copious details about the individual changes involved and the rationale for this change, but roughly, the idea is that by setting the environment variable `SOURCE_DATE_EPOCH`, which is [the preferred way to specify a fixed timestamp by the Reproducible Builds project](https://reproducible-builds.org/docs/source-date-epoch/), we will produce a fully reproducible archive. In any event, we will now produce consistent timestamps throughout the archive and avoid looking up the system time repeatedly.
If desired, I could hash the produced crate in the tests, but I feel that would be a little overkill, especially since it's possible that one of our dependencies (e.g., flate2) might change and result in us producing an equivalent but different archive. Since reproducible builds use a consistent toolchain, that's not a problem here.
Fixes#8612
Prior to this commit `cargo metadata` would not emit the value of a
target's "doc" setting, used by `cargo doc` to determine whether
documentation should be generated. However, this information is useful
for machine programs interested in such targets, and the information is
already made available on the internal representation of a target, so
this commit just exposes that during target serialization for emit.
cf https://github.com/deadlinks/cargo-deadlinks/issues/99
Currently, when reading a file from disk, we include several pieces of
data from the on-disk file, including the user and group names and IDs,
the device major and minor, the mode, and the timestamp. This means
that our archives differ between systems, sometimes in unhelpful ways.
In addition, most users probably did not intend to share information
about their user and group settings, operating system and disk type, and
umask. While these aren't huge privacy leaks, cargo doesn't use them
when extracting archives, so there's no value to including them.
Since using consistent data means that our archives are reproducible and
don't leak user data, both of which are desirable features, let's
canonicalize the header to strip out identifying information.
Omit the inclusion of the timestamp for generated files and tell the tar
crate to copy deterministic data. That will omit all of the data we
don't care about and also canonicalize the mode properly.
Our tests don't check the specifics of certain fields because they
differ between the generated files and the files that are archived from
the disk format. They are still canonicalized correctly for each type,
however.
Currently, when reading a file from disk, we include several pieces of
data from the on-disk file, including the user and group names and IDs,
the device major and minor, the mode, and the timestamp. This means
that our archives differ between systems, sometimes in unhelpful ways.
In addition, most users probably did not intend to share information
about their user and group settings, operating system and disk type, and
umask. While these aren't huge privacy leaks, cargo doesn't use them
when extracting archives, so there's no value to including them.
Since using consistent data means that our archives are reproducible and
don't leak user data, both of which are desirable features, let's
canonicalize the header to strip out identifying information.
We set the user and group information to 0 and root, since that's the
only user that's typically consistent among Unix systems. Setting
these values doesn't create a security risk since tar can't change the
ownership of files when it's running as a normal unprivileged user.
Similarly, we set the device major and minor to 0. There is no useful
value here that's portable across systems, and it does not affect
extraction in any way.
We also set the timestamp to the same one that we use for generated
files. This is probably the biggest loss of relevant data, but
considering that cargo doesn't otherwise use it and honoring it makes
the archives unreproducible, we canonicalize it as well.
Finally, we canonicalize the mode of an item we're storing by looking at
the executable bit and using mode 755 if it's set and mode 644 if it's
not. We already use 644 as the default for generated files, and this is
the same algorithm that Git uses to determine whether a file should be
considered executable. The tests don't test this case because there's
no portable way to create executable files on Windows.
Check if rust-src contains a vendor dir, and patch it in
This is the cargo side of https://github.com/rust-lang/wg-cargo-std-aware/issues/23
Note that this design naively assumes there is only one version of each package. It does not robustly verify this, and will presumably just cryptically fail to resolve dependencies.
See https://github.com/rust-lang/rust/pull/78790 for the other half of this change.
