feat(update): Include a Locking message
### What does this PR try to resolve?
This extends #13561 to `cargo update`. I previously left it out because the locking message was redundant. However the `Locking` message has been extended in #13754 to include the resolving policy which can be a useful point of interest (e.g. "why does `cargo update` do nothing? Oh, `-Zminimal-versions` is enabled").
I still left out the message for `--precise` because the user is overriding all of that.
I'd still like to extend all of this to `cargo install` (and maybe all resolves) but that is taking more investigation.
### How should we test and review this PR?
### Additional information
chore(deps): update rust crate gix to 0.62.0 [security]
[](https://renovatebot.com)
This PR contains the following updates:
| Package | Type | Update | Change |
|---|---|---|---|
| [gix](https://togithub.com/Byron/gitoxide) | workspace.dependencies | minor | `0.61.0` -> `0.62.0` |
### GitHub Vulnerability Alerts
#### [GHSA-98p4-xjmm-8mfh](https://togithub.com/Byron/gitoxide/security/advisories/GHSA-98p4-xjmm-8mfh)
### Summary
`gix-transport` does not check the username part of a URL for text that the external `ssh` program would interpret as an option. A specially crafted clone URL can smuggle options to SSH. The possibilities are syntactically limited, but if a malicious clone URL is used by an application whose current working directory contains a malicious file, arbitrary code execution occurs.
### Details
This is related to the patched vulnerability https://github.com/advisories/GHSA-rrjw-j4m2-mf34, but appears less severe due to a greater attack complexity. Since [https://github.com/Byron/gitoxide/pull/1032](https://togithub.com/Byron/gitoxide/pull/1032), `gix-transport` checks the host and path portions of a URL for text that has a `-` in a position that will cause `ssh` to interpret part of all of the URL as an option argument. But it does not check the non-mandatory username portion of the URL.
As in Git, when an address is a URL of the form `ssh://username@hostname/path`, or when it takes the special form `username@hostname:dirs/repo`, this is treated as an SSH URL. `gix-transport` will replace some characters in `username` with their `%`-based URL encodings, but otherwise passes `username@hostname` as an argument to the external `ssh` command. This happens even if `username` begins with a hyphen. In that case, `ssh` treats that argument as an option argument, and attempts to interpret and honor it as a sequence of one or more options possibly followed by an operand for the last option.
This is harder to exploit than GHSA-rrjw-j4m2-mf34, because the possibilities are constrained by:
- The difficulty of forming an option argument `ssh` accepts, given that characters such as `=`, `/`, and `\`, are URL-encoded, `:` is removed, and the argument passed to `ssh` contains the ``@`` sign and subsequent host identifier, which in an effective attack must be parseable as a suffix of the operand passed to the last option.
The inability to include a literal `=` prevents the use of `-oNAME=VALUE` (e.g., `-oProxyCommand=payload`). The inability to include a literal `/` or `\` prevents smuggling in a path operand residing outside the current working directory, incuding on Windows. (Although a `~` character may be smuggled in, `ssh` does not perform its own tilde expansion, so it does not form an absolute path.)
- The difficulty, or perhaps impossibility, of completing a connection (other than when arbitrary code execution has been achieved). This complicates or altogether prevents the use of options such as `-A` and `-X` together with a connection to a real but malicious server. The reason a connection cannot generally be completed when exploiting this vulnerability is that, because the argument `gix-transport` intends as a URL is treated as an option argument, `ssh` treats the subsequent non-option argument `git-upload-pack` as the host instead of the command, but it is not a valid host name.
Although `ssh` supports aliases for hosts, even if `git-upload-pack` could be made an alias, that is made difficult by the URL-encoding transformation.
However, an attacker who is able to cause a specially named `ssh` configuration file to be placed in the current working directory can smuggle in an `-F` option referencing the file, and this allows arbitrary command execution.
This scenario is especially plausible because programs that operate on git repositories are often run in untrusted git repositories, sometimes even to operate on another repository. Situations where this is likely, such that an attacker could predict or arrange it, may for some applications include a malicious repository with a malicious submodule configuration.
Other avenues of exploitation exist, but appear to be less severe. For example, the `-E` option can be smuggled to create or append to a file in the current directory (or its target, if it is a symlink). There may also be other significant ways to exploit this that have not yet been discovered, or that would arise with new options in future versions of `ssh`.
### PoC
To reproduce the known case that facilitates arbitrary code execution, first create a file in the current directory named `configfile@example.com`, of the form
```text
ProxyCommand payload
```
where `payload` is a command with an observable side effect. On Unix-like systems, this could be `date | tee vulnerable` or an `xdg-open`, `open`, or other command command to launch a graphical application. On Windows, this could be the name of a graphical application already in the search path, such as `calc.exe`.
(Although the syntax permitted in the value of `ProxyCommand` may vary by platform, this is not limited to running commands in the current directory. That limitation only applies to paths directly smuggled in the username, not to the contents of a separate malicious configuration file. Arbitrary other settings may be specified in `configfile@example.com` as well.)
Then run:
```sh
gix clone 'ssh://-Fconfigfile@example.com/abc'
```
Or:
```sh
gix clone -- '-Fconfigfile@example.com:abc/def'
```
(The `--` is required to ensure that `gix` is really passing the argument as a URL for use in `gix-transport`, rather than interpreting it as an option itself, which would not necessarily be a vulnerability.)
In either case, the payload specified in `configfile@example.com` runs, and its side effect can be observed.
Other cases may likewise be produced, in either of the above two forms of SSH addresses. For example, to create or append to the file `errors@example.com`, or to create or append to its target if it is a symlink:
```sh
gix clone 'ssh://-Eerrors@example.com/abc'
```
```sh
gix clone -- '-Eerrors@example.com:abc/def'
```
### Impact
As in https://github.com/advisories/GHSA-rrjw-j4m2-mf34, this would typically require user interaction to trigger an attempt to clone or otherwise connect using the malicious URL. Furthermore, known means of exploiting this vulnerability to execute arbitrary commands require further preparatory steps to establish a specially named file in the current directory. The impact is therefore expected to be lesser, though it is difficult to predict it with certainty because it is not known exactly what scenarios will arise when using the `gix-transport` library.
Users who use applications that make use of `gix-transport` are potentially vulnerable, especially:
- On repositories with submodules that are automatically added, depending how the application manages submodules.
- When operating on other repositories from inside an untrusted repository.
- When reviewing contributions from untrusted developers by checking out a branch from an untrusted fork and performing clones from that location.
---
### Release Notes
<details>
<summary>Byron/gitoxide (gix)</summary>
### [`v0.62.0`](https://togithub.com/Byron/gitoxide/releases/tag/gix-v0.62.0): gix v0.62
[Compare Source](https://togithub.com/Byron/gitoxide/compare/gix-v0.61.1...gix-v0.62.0)
Please note that this release contains a security fix originally implemented in `gix-transport` via [this PR](https://togithub.com/Byron/gitoxide/pull/1342) which prevents `ssh` options to be smuggled into the `ssh` command-line invocation with a username provided to a clone or fetch URL.
Details can be found [in the advisory](https://togithub.com/Byron/gitoxide/security/advisories/GHSA-98p4-xjmm-8mfh).
##### Bug Fixes
- `into_index_worktree_iter()` now takes an iterator, instead of a Vec.
This makes the API more consistent, and one can pass `None`
as well.
- show submodules in status independently of their active state.
Even inactive submodules are shown in the status by `git status`,
so `gix` should do the same.
First observed in [https://github.com/helix-editor/helix/pull/5645#issuecomment-2016798212](https://togithub.com/helix-editor/helix/pull/5645#issuecomment-2016798212)
- forward `curl` rustls feature from `gix-transport` to avoid `curl` in `gix`.
This removes the `curl` dependency just for configuring it, and removes
a hazard which became evident with reqwest.
##### Bug Fixes (BREAKING)
- Make `topo` more similar to `Ancestors`, but also rename `Ancestors` to `Simple`
##### Commit Statistics
- 16 commits contributed to the release over the course of 20 calendar days.
- 22 days passed between releases.
- 4 commits were understood as [conventional](https://www.conventionalcommits.org/).
- 1 unique issue was worked on: [https://github.com/Byron/gitoxide/issues/1328](https://togithub.com/Byron/gitoxide/issues/1328)
##### Thanks Clippy
[Clippy](https://togithub.com/rust-lang/rust-clippy) helped 1 time to make code idiomatic.
##### Commit Details
- **[https://github.com/Byron/gitoxide/issues/1328](https://togithub.com/Byron/gitoxide/issues/1328)**
- Forward `curl` rustls feature from `gix-transport` to avoid `curl` in `gix`. (98cfbec512)
- **Uncategorized**
- Prepare changelogs prior to release (57552717f4)
- Merge pull request [https://github.com/Byron/gitoxide/pull/1341](https://togithub.com/Byron/gitoxide/pull/1341) from szepeviktor/typos (55f379bc47)
- Fix typos (f72ecce45b)
- Merge branch 'add-topo-walk' (b590a9d2b6)
- Adapt to changes in `gix-traverse` (1cfeb11f1f)
- Make `topo` more similar to `Ancestors`, but also rename `Ancestors` to `Simple` (2a9c178326)
- Adapt to changes in `gix-traverse` (6154bf3a34)
- Thanks clippy (7f6bee5452)
- Merge branch 'status' (45edd2ea66)
- `into_index_worktree_iter()` now takes an iterator, instead of a Vec. (18b2921aaa)
- Show submodules in status independently of their active state. (719ced8a79)
- Make it easier to discover `is_path_excluded()` in documentation (c13632959e)
- Adapt to changes in `gix-index` (1e1fce11a9)
- Merge branch 'patch-1' (9e9c653a83)
- Remove dep reqwest from gix (e3eedd8b53)
### [`v0.61.1`](https://togithub.com/Byron/gitoxide/releases/tag/gix-v0.61.1): gix v0.61.1
[Compare Source](https://togithub.com/Byron/gitoxide/compare/gix-v0.61.0...gix-v0.61.1)
This release also updates `reqwest` to v0.12, bringing hyper 1.0 and a more recent `rustls` version.
##### Bug Fixes
- missing closing backtick in gix lib documentation
##### Commit Statistics
- 7 commits contributed to the release over the course of 2 calendar days.
- 3 days passed between releases.
- 1 commit was understood as [conventional](https://www.conventionalcommits.org).
- 0 issues like '(#ID)' were seen in commit messages
##### Commit Details
<csr-read-only-do-not-edit/>
<details><summary>view details</summary>
- **Uncategorized**
- Prepare changelogs prior to release ([`7018a92`](https://togithub.com/Byron/gitoxide/commit/7018a92))
- Merge branch 'patch-1' ([`8fde62b`](https://togithub.com/Byron/gitoxide/commit/8fde62b))
- Turn`curl` into a workspace package ([`adee500`](https://togithub.com/Byron/gitoxide/commit/adee500))
- Make reqwest a workspace package ([`369cf1b`](https://togithub.com/Byron/gitoxide/commit/369cf1b))
- Merge pull request [#​1325](https://togithub.com/Byron/gitoxide/issues/1325) from kdelorey/fix/simple-docs-formatting ([`3b34699`](https://togithub.com/Byron/gitoxide/commit/3b34699))
- Fixed opening of backtick in documentation. ([`f1bc4cd`](https://togithub.com/Byron/gitoxide/commit/f1bc4cd))
- Missing closing backtick in gix lib documentation ([`e1fec3c`](https://togithub.com/Byron/gitoxide/commit/e1fec3c))
</details>
</details>
---
### Configuration
📅 **Schedule**: Branch creation - "" (UTC), Automerge - At any time (no schedule defined).
🚦 **Automerge**: Disabled by config. Please merge this manually once you are satisfied.
♻ **Rebasing**: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.
🔕 **Ignore**: Close this PR and you won't be reminded about this update again.
---
- [ ] <!-- rebase-check -->If you want to rebase/retry this PR, check this box
---
This PR has been generated by [Mend Renovate](https://www.mend.io/free-developer-tools/renovate/). View repository job log [here](https://developer.mend.io/github/rust-lang/cargo).
<!--renovate-debug:eyJjcmVhdGVkSW5WZXIiOiIzNy4yOTMuMCIsInVwZGF0ZWRJblZlciI6IjM3LjI5My4wIiwidGFyZ2V0QnJhbmNoIjoibWFzdGVyIiwibGFiZWxzIjpbXX0=-->
feat(resolve): Tell the user the style of resovle done
### What does this PR try to resolve?
This is to help with https://github.com/rust-lang/cargo/issues/9930
Example changes:
```diff
-[LOCKING] 4 packages
+[LOCKING] 4 packages to latest compatible version
-[LOCKING] 2 packages
+[LOCKING] 2 packages to latest Rust 1.60.0 compatible versions
-[LOCKING] 2 packages
+[LOCKING] 2 packages to earliest compatible versions
```
Benefits
- The package count is of "added" packages and this makes that more
logically clear
- This gives users transparency into what is happening, especially with
- what rust-version is use
- the transition to this feature in the new edition
- whether the planned config was applied or not (as I don't want it to
require an MSRV bump)
- Will make it easier in tests to show what changed
- Provides more motiviation to show this message in `cargo update` and
`cargo install` (that will be explored in a follow up PR)
This does come at the cost of more verbose output but hopefully not too
verbose. This is why I left off other factors, like avoid-dev-deps.
### How should we test and review this PR?
### Additional information
docs: update `checkout` GitHub action version
### What does this PR try to resolve?
This PR updates the GitHub CI examples in The Cargo Book to use the latest version of the `actions/checkout` GitHub action, since using `actions/checkout@v3` (currently used in the examples) produces warnings about deprecated Node.js 16 (see also [GitHub Actions: Transitioning from Node 16 to Node 20](https://github.blog/changelog/2023-09-22-github-actions-transitioning-from-node-16-to-node-20/) blog post).
Also, v4 is already used in the "Verifying `rust-version`" example:
a9f86addbc/src/doc/src/guide/continuous-integration.md?plain=1#L174
Recategorize cargo test's `--doc` flag under "Target Selection"
### What does this PR try to resolve?
In `cargo help test`, the `--doc` flag is listed under a section called "Target Selection" next to `--lib`, `--bin`, `--bins`, `--example`, `--examples`, `--test`, `--tests`, `--bench`, `--benches`, and `--all-targets`.
But in `cargo test --help`, it was instead listed in an "Options" section next to `--no-run`, `--message-format`, `--color`, etc, which seems less appropriate than "Target Selection".
### How should we test and review this PR?
- `cargo build --release`
- `cargo test --release --test testsuite -- cargo_test::help::case`
- `target/release/cargo test --help`
- `target/release/cargo help test` (unchanged)
This is to help with #9930
Example changes:
```diff
-[LOCKING] 4 packages
+[LOCKING] 4 packages to latest version
-[LOCKING] 2 packages
+[LOCKING] 2 packages to latest Rust 1.60.0 compatible versions
-[LOCKING] 2 packages
+[LOCKING] 2 packages to earliest versions
```
Benefits
- The package count is of "added" packages and this makes that more
logically clear
- This gives users transparency into what is happening, especially with
- what rust-version is use
- the transition to this feature in the new edition
- whether the planned config was applied or not (as I don't want it to
require an MSRV bump)
- Will make it easier in tests to show what changed
- Provides more motiviation to show this message in `cargo update` and
`cargo install` (that will be explored in a follow up PR)
This does come at the cost of more verbose output but hopefully not too
verbose. This is why I left off other factors, like avoid-dev-deps.
Reword sentence describing workspace toml for clarity
Judging by the commit history, the original sentence was written before the `[patch]` and `[profile]` sections were added and since those sections do not go underneath the workspace table the original sentence needed to be updated.
Judging by the commit history, the original sentence was written before the `[patch]` and `[profile]` sections were added and since those sections do not go underneath the workspace table the original sentence needed to be updated.
refactor(config): Consistently use kebab-case
This shouldn't change the behavior but makes it safer if
- We add new fields where it will matter
- Copy/paste these for new structs
I did not change things related to the Index because we are already stuck with that case (whether we want it or not)
Came across this when working on #13540 and almost made the mistake of copying what was already there
feat(resolve): Fallback to 'rustc -V' for MSRV resolving
### What does this PR try to resolve?
This is part of #9930 and adds a fallback if the rust-version isn't set
### How should we test and review this PR?
Tests are added in a separate commit so people can see how the behavior changed.
### Additional information
This shouldn't change the behavior but makes it safer if
- We add new fields where it will matter
- Copy/paste these for new structs
I did not change things related to the Index because we are already
stuck with that case (whether we want it or not)
feat(cli): Add --ignore-rust-version to update/generate-lockfile
### What does this PR try to resolve?
This is part of #9930 and extends `--ignore-rust-version` to `cargo update` and `cargo generate-lockfile`
### How should we test and review this PR?
First commit sets up tests
### Additional information
`cargo package -p no-exist` emitt error when the -p `package` not found
### What does this PR try to resolve?
Fixes#13719
If `-p` is used, and the spec doesn't match any member, we emit an error like `cargo publish -p` does.
### How should we test and review this PR?
The first commit add a test to show the issue, the next commit add the check logic to fix it.
### Additional information
fix(help): Generalize --ignore-rust-version
### What does this PR try to resolve?
This is part of #9930 and updates for the help to accommodate #13738 and adding `--ignore-rust-version` to `cargo update` for when they are stable
This includes
- Moving `--ignore-rust-version` to be under the "Manifest options" header
- Generalizing the help description
### How should we test and review this PR?
### Additional information
test: don't compress test registry crates
They are still nominally gzipped, but using `Compression::none()` makes
them consistent even across zlib and zlib-ng, and this fixes checksum
differences in the testsuite. There is a one-time update of all those
checksums to catch up with this change though.
r? `@weihanglo`
feat(reslve): Respect '--ignore-rust-version'
### What does this PR try to resolve?
This is a part of #9930.
### How should we test and review this PR?
I had considered several ways of implementing this. I first looked at passing this into `ops::resolve*`.
.This would get a bit annoying with the function signature, so I considered moving it to a builder..
Each of the entry points is slightly different with different ownership needs, making it hard to have a common abstraction.
In doing this, I noticed we currently pass some state around to the resolver via `Workspace`, so I mirrored that.
The nice thing about this location is it provides a good place to hook in config and `package.resolve` so they affect this.
### Additional information
They are still nominally gzipped, but using `Compression::none()` makes
them consistent even across zlib and zlib-ng, and this fixes checksum
differences in the testsuite. There is a one-time update of all those
checksums to catch up with this change though.
refactor: Remove `rust_2024_compatibility` lint group
The `rust_2024_compatibility` lint group was added as a way to be compatible with `Rust`. This group is meant to be used when switching to the 2024 edition (usually enabled by `cargo fix --edition`). Since we are not going to be interacting with `cargo fix` in the standard way to fix edition lints, this group is not needed at this time. Removing this will (slightly) reduce the complexity of working on things for the 2024 edition.
bors
Weihang Lo
renovate[bot]
Ed Page
Naglis Jonaitis
David Tolnay
jw013
Ralf Jung
Lin Yihai
Josh Stone
Scott Schafer
