development/cargo
development/cargo
1
0
Fork 0
mirror of https://github.com/rust-lang/cargo synced 2024-10-04 06:49:15 +00:00
Code Issues Packages Projects Releases Wiki Activity
10230 commits 80 branches 101 tags 90 MiB
Rust 95.2%
Roff 4.4%
JavaScript 0.2%
Shell 0.1%
Find a file
bors 8917837fb6 Auto merge of #8934 - ehuss:token-process, r=alexcrichton 
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.
2020-12-14 16:22:53 +00:00
.github Implement credential-process. 2020-12-02 19:09:54 -08:00
ci Fix man CI validation. 2020-10-17 11:47:18 -07:00
crates Auto merge of #8934 - ehuss:token-process, r=alexcrichton 2020-12-14 16:22:53 +00:00
src Auto merge of #8934 - ehuss:token-process, r=alexcrichton 2020-12-14 16:22:53 +00:00
tests Auto merge of #8934 - ehuss:token-process, r=alexcrichton 2020-12-14 16:22:53 +00:00
.gitignore add VS Code user dir to .gitignore 2019-11-11 10:35:40 +02:00
build.rs Build manpage archive deterministically 2020-08-10 06:47:00 -07:00
Cargo.toml Remove version from dev-dependencies to make it easier to publish. 2020-11-30 08:12:02 -08:00
CHANGELOG.md Update changelog for 1.49 2020-11-23 17:38:14 -08:00
CONTRIBUTING.md Add contributor guide. 2020-09-18 14:01:51 -07:00
LICENSE-APACHE HTTPS all the things 2019-01-30 15:34:37 -05:00
LICENSE-MIT Remove inaccurate (misattributed) copyright notices 2017-07-26 17:19:24 -07:00
LICENSE-THIRD-PARTY HTTPS all the things 2019-01-30 15:34:37 -05:00
publish.py Fix self-publish script. 2020-07-16 15:21:51 -07:00
README.md Add contributor guide. 2020-09-18 14:01:51 -07:00
triagebot.toml Add triagebot configuration 2020-03-31 11:15:46 -04:00

README.md

Cargo

Cargo downloads your Rust project’s dependencies and compiles your project.

Learn more at https://doc.rust-lang.org/cargo/

Code Status

Build Status

Code documentation: https://docs.rs/cargo/

Installing Cargo

Cargo is distributed by default with Rust, so if you've got rustc installed locally you probably also have cargo installed locally.

Compiling from Source

Cargo requires the following tools and packages to build:

  • git
  • curl (on Unix)
  • pkg-config (on Unix, used to figure out the libssl headers/libraries)
  • OpenSSL headers (only for Unix, this is the libssl-dev package on ubuntu)
  • cargo and rustc

First, you'll want to check out this repository

git clone https://github.com/rust-lang/cargo
cd cargo

With cargo already installed, you can simply run:

cargo build --release

Adding new subcommands to Cargo

Cargo is designed to be extensible with new subcommands without having to modify Cargo itself. See the Wiki page for more details and a list of known community-developed subcommands.

Releases

Cargo releases coincide with Rust releases. High level release notes are available as part of Rust's release notes. Detailed release notes are available in this repo at CHANGELOG.md.

Reporting issues

Found a bug? We'd love to know about it!

Please report all issues on the GitHub issue tracker.

Contributing

See the Cargo Contributor Guide for a complete introduction to contributing to Cargo.

License

Cargo is primarily distributed under the terms of both the MIT license and the Apache License (Version 2.0).

See LICENSE-APACHE and LICENSE-MIT for details.

Third party software

This product includes software developed by the OpenSSL Project for use in the OpenSSL Toolkit (https://www.openssl.org/).

In binary form, this product includes software that is licensed under the terms of the GNU General Public License, version 2, with a linking exception, which can be obtained from the upstream repository.

See LICENSE-THIRD-PARTY for details.