GHSA-qppj-fm5r-hxr3 - How do we proceed with adding new packages?

[spiffcs]

Summary

GHSA-qppj-fm5r-hxr3 is currently linked via aliases to CVE-2023-44487. It contains packages from two different ecosystems (swift, and golang). Would the github advisories team accept a PR that adds more packages to this entry as enumerated by the Known Affected Software Configurations on CVE-2023-44487?

Since the record is specifically filed for the swift-nio-http2 implementation is it better to get a new GHSA created per specific package found in the configurations?

I'd like to start getting these cataloged in the advisory database, but want to make sure I'm doing it in a way that the team agrees on.

I saw #2908 had been filed to modify GHSA-xpw8-rcwv-8f8p (the netty codec implementation of this broad CVE) which added a reference as an identifier given that the alias was already taken by GHSA-qppj-fm5r-hxr3.

It seems there are two approaches currently in the data:

1. Individual GHSA per implementation or package with a reference link to the upstream CVE

2. The original auto aliased GHSA which contains information specific to swift, but also has separate, but semi related golang packages as a part of the affected packages list.

I would love to hear the teams thoughts on what they view as the correct orientation for adding more packages to the database that are listed as vulnerable under this CVE =)

Related issue: #2869

[spiffcs]

@darakian - I would love your input after talking with @jhutchings1 - He says you have the important opinion that matters on this one =)

[darakian]

Hey @spiffcs I think we may have covered this in person at universe last week, but for the completeness of this thread....

Would the github advisories team accept a PR that adds more packages to this entry as enumerated by the Known Affected Software Configurations on GHSA-qppj-fm5r-hxr3? Since the record is specifically filed for the swift-nio-http2 implementation is it better to get a new GHSA created per specific package found in the configurations?

Yes. We attempt to index any relevant packages for a CVE/GHSA. For cases like this where the issue is more to do with a protocol rather than a piece of code that list can obviously grow. I think if you do want to make that PR we should take the time to make the description generic as well since the current version reads very much like it's only about the swift package.

The netty example is an interesting one too where the maintainer proactively made a repo GHSA to alert their users about the issue and indeed because of our 1-1 mapping between CVEs and GHSAs we couldn't merge that into the other one for the reviewed set. I guess we could have, but then we would be missing the GHSA that the maintainer published and that's also not great.

On the 1-1 cve-ghsa linkage; handling advisory updates becomes super annoying if you've got a many to many relationship which is likely what would be ideal from a data perspective. Hence we have that constraint. So, what we try to do is handle these cases one by one. We want maintainers to be proactive and write their own GHSAs to alert their users asap, but we also want to dedupe the data as best we can. So for this case I think it makes sense to re-write the CVE/GHSA assigned to the protocol error as a more generic advisory and to list relevant packages on it.

[KateCatlin]

Hey @spiffcs any last questions on this thread or shall we close this issue out?

[spiffcs]

Thanks @KateCatlin! Jon's answer is perfect guidance here. When I get some cycles this weekend/next week I can make a PR that get's us moving where the description is generic and then starts to add additional packages.

[KateCatlin]

Amazing thank you so much @spiffcs and @darakian! Love the teamwork here :)