4 ms·

isn't the issue that sometimes a given scanner can't know from where the package is sourced? like if I'm scanning an arbitrary linux system, and I see `libssl.

isn't the issue that sometimes a given scanner can't know from where the package is sourced? like if I'm scanning an arbitrary linux system, and I see `libssl.so.1` but I don't see it in the local package manager, I don't really have an option other than to call it generic. I do agree that "generic" seems to be WAY overused though. Maybe tools that report on SBOMs, like FOSSA or whatever, should emit warnings to users about "generic" PURLs.

donenext 1y ago
Thats fair. It just seems silly that a spec intended to "uniquely ID a package" supports a type that is the complete opposite of "unique". I guess another way to frame my take is should `generic` be consider a valid PURL? Keep it as a fall back sure, but distinguish between "fully qualified" PURLs and "partial" PURLs. This then gives tooling a path to prompt users to provide missing context needed to fully qualify the PURL
- pombreda 1y ago
  > distinguish between "fully qualified" PURLs and "partial" PURLs. Can you tell a bit more? Not sure I get what you meant
- jessoteric 1y ago
  That seems like a good idea... hmm.
pombreda 1y ago
> 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.

donenext 1y ago

Thats fair. It just seems silly that a spec intended to "uniquely ID a package" supports a type that is the complete opposite of "unique". I guess another way to frame my take is should `generic` be consider a valid PURL? Keep it as a fall back sure, but distinguish between "fully qualified" PURLs and "partial" PURLs. This then gives tooling a path to prompt users to provide missing context needed to fully qualify the PURL

pombreda 1y ago
> distinguish between "fully qualified" PURLs and "partial" PURLs. Can you tell a bit more? Not sure I get what you meant
jessoteric 1y ago
That seems like a good idea... hmm.

pombreda 1y ago

> 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.