Informational RUSTSEC advisories and GHSA

[EliahKagan]

RUSTSEC-2024-0359 (#1460) is informational and not known to give rise to any security vulnerabilities, though it potentially could. It has been imported into the GitHub Advisory Database as GHSA-cx7h-h87r-jpgr.

I wanted to ensure this is known, in case there are any concerns. Some informational advisories should not be imported into GHSA, or are reasonable to import but have been imported in a way that overinflates their significance. However, in this case, I think it's reasonable and that no special action needs to be taken.

• While not known to be a vulnerability, and not a kind of unsoundness that is overwhelmingly likely to produce a vulnerability, this is relevant to security and a vulnerability could arise from it.
• Unlike some informational advisories such as those indicating that a crate is unmaintained, the GHSA for this advisory is usefully actionable: Dependabot facilitates an update to the fixed version.
• The severity is set to "low," which I think is a reasonable value.
• CWE-172 is listed as the applicable weakness, which is correct.
• The GHSA advisory has correct and useful references.

I'm willing to open an issue PR on the GitHub Advisory Database in case if anything needs to be corrected or if there is a good reason to consider this advisory's inclusion incorrect. But I think everything is fine and the only action to take, if any, would be the Dependabot-recommended update in the top-level Cargo.lock (which still refers to the old version).

[Byron]

Thanks for the update!

But I think everything is fine and the only action to take, if any, would be the Dependabot-recommended update in the top-level Cargo.lock (which still refers to the old version).

I don't think I follow - how can gix-attributes be updated here where it's always 'the latest' version?

[EliahKagan]

I don't think I follow - how can gix-attributes be updated here where it's always 'the latest' version?

If I understand correctly, Cargo.lock files, including the top-level Cargo.lock in a workspace, hold fully resolved dependencies, while still not imposing those specific versions on consumers of the project. If I am mistaken here and updating versions in Cargo.lock imposes a constraint on downstream users, then some of the following claims are likewise incorrect.

Among the fully resolved dependencies in the top-level Cargo.lock file are various explicit versions of some gix-* crates including gix-attributes. This currently is resolved at 0.22.2 for gix-worktree, which is probably what caused Dependabot to propose an update.

But I am unsure if this really can or should be improved. It seems the Dependabot security update offered in connection with the GHSA advisory itself actually cannot update it. When it tries, it finds all dependencies already to be at good versions, reporting:

No security update is needed as gix-attributes is no longer vulnerable

But the advisory does not automatically close, so I'm not sure what's going on with that. That Dependabot cannot actually update it yet to resolve its own report undercuts my claim that the Dependabot-related effect of the GHSA advisory is useful in this case. In any case, running cargo update would bump that version, among many others.

Edit: Condensed and clarified the wording.

[Byron]

Ah, maybe that one instance of gix-attributes is the one pulled in by the test-tools, which can't really use the workspace crates and thus resort to an older version from crates.io.
So I think this issue will resolve itself here eventually - the situation with gix-testtools is a bit of a mess and whenever an update happens, I risk not being able to publish next time because of problems with dependency resolution, I don't really know what's going on but can wiggle through it until it works.

[EliahKagan]

Ah, maybe that one instance of gix-attributes is the one pulled in by the test-tools, which can't really use the workspace crates and thus resort to an older version from crates.io.

That makes sense, and I was wondering why some are unversioned or list all zeros while others list versions from crates.io, which this seems to explain. The patched version of course crates.io and running cargo update will bump this to it, but I don't think that necessarily needs to be done.

the situation with gix-testtools is a bit of a mess and whenever an update happens, I risk not being able to publish next time because of problems with dependency resolution, I don't really know what's going on but can wiggle through it until it works.

I wonder if that's something that could be improved on. Is there information in any issues, PRs, comments, etc., about that problem?

[Byron]

I wonder if that's something that could be improved on. Is there information in any issues, PRs, comments, etc., about that problem?

No, and I settled with living with the issue which disappears once gix-testtools dependencies are at least one minor version away from what's current in the worktree. Issues only really appear when trying to publish crates, which isn't easy to do without side-effects. Further, cargo smart-release might also be involved, which is in the state of "it usually works, and if it doesn't there are workarounds, and it's used rarely enough to be fine like that and not worth the time to try and fix anything".

It's not a perfect state, but it's something I can live with for now. Long term, I think this could be fixed, but only once there isn't anything more important to do which probably isn't going to happen in a while.

[EliahKagan]

I agree with these priorities. I do hope that releasing can become simple and easy in the future. In particular, it might be useful to be able to publish prereleases easily, even if that never ends up being something that is habitually done, since then a greater degree of experimentation related to releasing might be eased (which could simplify investigating things like #1472, or maybe even avoid them).

I'm not sure why cargo smart-release would be contributing to the problem, but I think this is just due to my not knowing much about how it works, rather than there being any fundamental reason it could not. In any case, maybe whoever ends up contributing the cargo smart-release feature whose absence is currently blocking #1200 would in doing so gain the knowledge to improve it in other ways too. If no one else gets around to contributing that feature then I hope to do so, though at this moment it is not my top priority.

[Byron]

After gix went 1.0, cargo smart-release needs to be adjusted to be able to handle this better - after all it will then have to keep gix stable, sometimes despite breaking changes in plumbing which aren't exposed. But until then it just has to work.
It's notable that I spent considerable time even getting it this far, and the lack of journey tests probably is one reason it took so long. So making it more testable is probably the only thing it is really missing on the path to working really well.