You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It turns out the production (i.e. non-dev) dependencies on gix-* crates are still a version behind, so they use a version of gix-features that is affected by RUSTSEC-2025-0021.
Dependabot does show security advisories for this, which is why there are 18 open Dependabot advisories, rather than the 9 that there would be if the only use of affected gix-* crates were through gix-testtools. (For example, compare the Dependabot alerts page for this repository to the one for gitoxide.)
Dependabot is unable to create a security update for this. The reason is that it tries to update affected crates to unaffected versions across the whole dependency tree, but this is currently infeasible due to each version of gix-testtools depending on a previous major version of gix-* crates, as discussed in GitoxideLabs/gitoxide#1510 and GitoxideLabs/gitoxide#1886.
Just in case, though I didn't expect it to work, I changed the setting to use grouped security updates and manually triggered an attempt to create an update. As expected, this did not work.
I wondered if Dependabot version updates might be able and willing to proceed by updating everything as much as it can even though it is not perfect. The fork-internal experiment in EliahKagan#5 reveals that, while enabling Dependabot version updates would bump various other dependencies in potentially valuable ways (though also would require code changes to make tests pass), it would not include gix-features, nor any other gix-* crates, among those updated.
Thus, although it is my view is that grouped Dependabot version updates should be enabled for Rust dependencies in this repository (#52), that wouldn't do anything to fix this issue.
Running cargo update looks like a good way to fix this and like it would be the easiest way to do so. It looks like doing so will require at least one adjustment to make clippy happy, but that it is otherwise workable and effective.
I'm opening this issue anyway, mainly in case I don't manage to get around to doing that, so that this is not forgotten, but also because I would include these details in the PR anyway if they weren't here. Edit: I've done it in #51.
A clearer way to see the effect of upgrading is shown in this gist. For convenience:
This suggests that cargo update will bring us from using two vulnerable versions of gix-features one of which is used even outside the dev dependency on gix-testtools, to one version that is only used through gix-testtools. Thus, I will go with that unless I am unable to do so, or unless some problem arises with it.
Edit: I've opened #51, which I believe successfully fixes this.
The text was updated successfully, but these errors were encountered:
Uh oh!
There was an error while loading. Please reload this page.
It turns out the production (i.e. non-dev) dependencies on
gix-*
crates are still a version behind, so they use a version ofgix-features
that is affected by RUSTSEC-2025-0021.Dependabot does show security advisories for this, which is why there are 18 open Dependabot advisories, rather than the 9 that there would be if the only use of affected
gix-*
crates were throughgix-testtools
. (For example, compare the Dependabot alerts page for this repository to the one for gitoxide.)Dependabot is unable to create a security update for this. The reason is that it tries to update affected crates to unaffected versions across the whole dependency tree, but this is currently infeasible due to each version of
gix-testtools
depending on a previous major version ofgix-*
crates, as discussed in GitoxideLabs/gitoxide#1510 and GitoxideLabs/gitoxide#1886.Just in case, though I didn't expect it to work, I changed the setting to use grouped security updates and manually triggered an attempt to create an update. As expected, this did not work.
I wondered if Dependabot version updates might be able and willing to proceed by updating everything as much as it can even though it is not perfect. The fork-internal experiment in EliahKagan#5 reveals that, while enabling Dependabot version updates would bump various other dependencies in potentially valuable ways (though also would require code changes to make tests pass), it would not include
gix-features
, nor any othergix-*
crates, among those updated.Thus, although it is my view is that grouped Dependabot version updates should be enabled for Rust dependencies in this repository (#52), that wouldn't do anything to fix this issue.
Running
cargo update
looks like a good way to fix this and like it would be the easiest way to do so. It looks like doing so will require at least one adjustment to makeclippy
happy, but that it is otherwise workable and effective.I'm opening this issue anyway, mainly in case I don't manage to get around to doing that, so that this is not forgotten, but also because I would include these details in the PR anyway if they weren't here. Edit: I've done it in #51.
A clearer way to see the effect of upgrading is shown in this gist. For convenience:
This suggests that
cargo update
will bring us from using two vulnerable versions ofgix-features
one of which is used even outside the dev dependency ongix-testtools
, to one version that is only used throughgix-testtools
. Thus, I will go with that unless I am unable to do so, or unless some problem arises with it.Edit: I've opened #51, which I believe successfully fixes this.
The text was updated successfully, but these errors were encountered: