feat: include upstream/source name and version in purl #497
Conversation
ivanstanev
force-pushed
the
feat/upstream-in-purl
branch
3 times, most recently
from
c405b8e
to
5b86192
Compare
ivanstanev
force-pushed
the
feat/upstream-in-purl
branch
from
5b86192
to
fa7d9ff
Compare
ivanstanev
force-pushed
the
feat/upstream-in-purl
branch
2 times, most recently
from
2d6d283
to
4a1cb16
Compare
ivanstanev
force-pushed
the
feat/upstream-in-purl
branch
2 times, most recently
from
4f5e385
to
4832cda
Compare
ivanstanev
force-pushed
the
feat/upstream-in-purl
branch
from
4832cda
to
a28605e
Compare
The source version of a package may not be the same as the package version, which is why we should track them whenever they differ. This change ensures we populate an "upstream" qualifier (similarly to how Syft does this) with the source name and version. "upstream" is a non-standard qualifier, but matches Syft for consistency. Tracking the source version is important because Snyk's vuln intel on Debian is based on the source version not the binary version. Some packages like postgres-client have differing binary and source versions, which results in reporting false positives once the wrong vulnerable version range is matched.
ivanstanev
force-pushed
the
feat/upstream-in-purl
branch
from
a28605e
to
a45bc34
Compare
|
Expected release notes (by @ivanstanev) features:
|
| "version": "1.0.9.8.4", | ||
| }, | ||
| }, | ||
| Object { | ||
| "id": "libsigsegv/libsigsegv2@2.10-4+b1", | ||
| "info": Object { | ||
| "name": "libsigsegv/libsigsegv2", | ||
| "purl": "pkg:deb/libsigsegv2@2.10-4%2Bb1?upstream=libsigsegv%402.10-4", |
There was a problem hiding this comment.
An example of a properly encoded purl 🙏
There was a problem hiding this comment.
🎉
Note: we only attach the upstream qualifier if the Source is set - we omit it if the package doesn't have a source set.
I know we decided that we're always adding the source even if it may be equal to the package name, but I agree that in the case of the source not being set at all, this hasn't been decided 😄
I'm approving this PR, as I don't have any objections to omitting it if it's not set in the apt-DB.
I'll leave it to you to decide :)
| "version": "5.6", | ||
| }, | ||
| }, | ||
| Object { | ||
| "id": "openssl/libssl1.1@1.1.1d-0+deb10u3", | ||
| "info": Object { | ||
| "name": "openssl/libssl1.1", | ||
| "purl": "pkg:deb/libssl1.1@1.1.1d-0%2Bdeb10u3?upstream=openssl", |
There was a problem hiding this comment.
I just added a test to our container-sbom-export library and that doesn't seem to escape the special chars:
pkg:deb/debian/libssl1.1@1.1.1d-0+deb10u3?upstream=openssl&distro=buster
I'm wondering if it should really be escaped? 🤔
There was a problem hiding this comment.
I guess it's the purl libraries that behave differently, as the TS seems to escape it and the Go one doesn't? 🥴
There was a problem hiding this comment.
The Purl spec says that "purl is just a URL", so I'd argue URL rules apply.
That means however that a plus-sign is a valid character and does not need to be escaped unless it's in the query component of the URL.
See this S/O answer for more details.
There was a problem hiding this comment.
purl's Go library's Parse function calls a url.PathUnescape function, which mentions in it's docs that:
PathUnescape is identical to QueryUnescape except that it does not unescape '+' to ' ' (space).
😄
So both examples (escaped and not) work!
And the JS library behaves the same!
So both are valid :)
There was a problem hiding this comment.
Thanks for checking! Fascinating differences 😄 But that suggests that the SBOM export not encoding the + will break in vuln when we try to parse it, resulting in a broken version?
|
🎉 This PR is included in version 6.4.0 🎉 The release is available on: Your semantic-release bot 📦🚀 |
What does this PR do?
The source version of a package may not be the same as the package version, which is why we should track them whenever they differ. This change ensures we populate an "upstream" qualifier (similarly to how Syft does this) with the source name and version. "upstream" is a non-standard qualifier, but matches Syft for consistency.
Tracking the source version is important because Snyk's vuln intel on Debian is based on the source version not the binary version. Some packages like postgres-client have differing binary and source versions, which results in reporting false positives once the wrong vulnerable version range is matched.