> It's just a single line of text might not be enough to encode build configurations.
that's the tough part, and IMHO outside of PURL? ... Note that for C/C++ code ... @alcroito mentions cps in the same comment page at https://news.ycombinator.com/item?id=44196246 ... and a quick glance is that this attempts to capture these details may be?
For "generic" interface-based dependencies, that's tougher.
This is a problem with a few ecosystems. OTH rpms, debs and Java OSGI... and may be a few more. We need to survey these to find if we can solve that and if this is a PURL problem at all.
Can I rope you in and interest you in filing an issue in the spec so we can move the discussion there? :P This would be great.
Good point, but that's may not be in scope either... since this is not even something you can get from Debian easily: not just looking at a Debian pool or diving into a package control files AFAIK?
Say I rebuild a Debian package with some new build options.
Is this a the same or a new package? I'd say a new one.
Is this the same name? I'd say a new one.
Is this distributed by Debian? Nope, so this comes from another repo and pool, right?
The idea with PURL is to have simple and short PURLs for the common case, and make it possible to handle less common cases. Rebuilding a package and sharing it on another repo would be a less common case to me? WDYT?
let's chat. There is a really a lot of folks interesting because of the suffering!
ABOUT is just a suggestion, and an TIL about cps and it looks awesome!
[email protected]
Or a comment on the issue or doc linked.
IMHO, a bare git stuff would be a git URL as specified in pip and SPDX and not a PURL... I would be interested to know more about your use case. Feel free to drop a note at [email protected]
All abstractions leak eventually, so we need that escape hatch IMHO. Otherwise you end up with the other issue which is that there are stuff you cannot track with PURL?
> isn't the issue that sometimes a given scanner can't know from where the package is sourced?
That's the problem: there is no metadata with or in libssl.so.1 that I can reliably use to tell what this is
Eventually I can see a solution made of
1. create the metadata, say a simple YAMl or deb822 key-valud pair file that can then be included upstream or as an overlay
2. define a simple spec for binary formats to include a PURL (say in an ELF section or a WinPE string or sorts, where many of these are already stored)
3. create content-based tools like we have in PurlDB to match code, but may be more like a bunch of generated yara rules that would match symbols and strings from source to binaries and can recognize that libssl.so.1 is from OpenSSL 1.1.1g.
And based on that approach we can either:
1. create new, sensible types as needed
2. and/or maintain a last resort open registry of generic types at least so we get some sanity in the process.
Is this about Maven "groupid" mapped to a namespace? "com.foo.bar" is Maven's own invention and notation.... in most cases we are just trying to adopt the ecosystem convention to minimize fictions.
Yeah, the CPE idea of a vendor for an open source package does not compute too well!
FWIW, PURL came about as I could NOT put my mind around CPEs when I was scanning for package and deps with scancode and could not find any easy way to go from that to looking up a vulnerability/CVE in the NVD, as it was all guesswork and manual.
So we started instead to put the vuln data in our own db, keyed by something that would be easy to relate from the scans. This eventually became PURL
If you want to chip in and help, this would be awesome.
And IMHO, aligned with your thinking this should not be tied to a build system or a for-profit operation like conan.io, or a linux distro, or for that matter a specific build tool or approach as they are so many, and be self-hosted, easy to sync, and simple to store in a git repo.
> It's just a single line of text might not be enough to encode build configurations.
that's the tough part, and IMHO outside of PURL? ... Note that for C/C++ code ... @alcroito mentions cps in the same comment page at https://news.ycombinator.com/item?id=44196246 ... and a quick glance is that this attempts to capture these details may be?
So it could be a happy combo?