[jessoteric]

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.

[pombreda]

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

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]

> distinguish between "fully qualified" PURLs and "partial" PURLs.

Can you tell a bit more? Not sure I get what you meant

[jessoteric]

That seems like a good idea... hmm.