Suggestion: File RUSTSEC advisories for security relevant updates

[egfx-notifications]

Hi, since some of the previous releases included security fixes in the linked C libraries, I'd like to suggest that RUSTSEC advisories for the affected versions are made and the affected versions yanked from crates.io, see https://github.com/RustSec/advisory-db/blob/main/CONTRIBUTING.md#reporting-vulnerabilities

The CVEs listed in the changelogs of the C libraries should probably go into the related section of each advisory.

I'm wondering if this is something you would be willing to do or if this is out of scope for this project, but I think it would benefit users of this library who would then be notified about necessary updates with tools like cargo-audit or cargo-deny.

I'm also not quite sure if this should be done with every security relevant dependency update in general or if we need to figure out if the vulnerable code paths were actually reachable when using this library. While this would lead to less and more accurate advisories, it would also require more work prior to submitting an advisory, so I'd be fine to just recommend an update in general regardless of exploitability of the specific vulnerability.

[scouten-adobe]

Thanks, @egfx-notifications, this seems very much worth considering. We're in a bit of a crunch mode on another project right now, but expect to discuss in a week or two.

[egfx-notifications]

Great, looking forward to it :)

[8573]

I note that, while the maintainers of a crate are generally the most knowledgeable people to write a RustSec advisory for their crate, it's not required that the maintainers themselves write the advisory; another interested person could write the advisory if the maintainers are too otherwise busy.

[crandmck]

@adobe export issue to Jira project CAI

[github-jira-sync-bot]

✅ Jira issue https://jira.corp.adobe.com/browse/CAI-3387 is successfully created for this GitHub issue.

[egfx-notifications]

I note that, while the maintainers of a crate are generally the most knowledgeable people to write a RustSec advisory for their crate, it's not required that the maintainers themselves write the advisory; another interested person could write the advisory if the maintainers are too otherwise busy.

I know, but it would be nice to have a defined process that is supported by the maintainers. Especially because a third-party can write advisories, but not remove the affected versions from crates.io
For now I'm willing to wait what becomes of this issue.

[egfx-notifications]

@adobe export issue to Jira project CAI

@crandmck May I assume that you will reflect progress from your internal JIRA to this issue when appropriate?

[crandmck]

May I assume that you will reflect progress from your internal JIRA to this issue when appropriate?

Yes, that's a reasonable assumption.

[scouten-adobe]

Very very reply to this issue. Another issue (#230) was recently filed that qualified as a RUSTSEC vulnerability (https://rustsec.org/advisories/RUSTSEC-2024-0360.html) due to undefined behavior. All versions of xmp_toolkit prior to 1.9.0 will now be flagged by cargo deny and similar.

Closing this issue as fixed.

[8573]

a RUSTSEC vulnerability (https://rustsec.org/advisories/RUSTSEC-2024-0360.html) due to undefined behavior

This advisory is marked as "informational" ("INFO"), which means that the issue is not considered a full vulnerability and is not treated as necessarily a problem by cargo-audit and cargo-deny (it would trigger a warning rather than an error). I don't know what "[t]he CVEs listed in the changelogs of the C libraries" were (I don't see where the changelogs of the C libraries are), but some or all of them might be more serious vulnerabilities that would trigger stronger action from cargo-audit and cargo-deny.