pombreda

:D

Yeah, this is messed up! But tell me when you cannot locate a correct PURL?

Actually, this is a locator alright. You can resolve a PURL to an actual package in an actual location.

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]

Can you tell a bit more? What is this? The OP article?

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?

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

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

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

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.