pombreda

4 ms·

1.
by pombreda 1y ago
You wrote: > 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 commen
2.
by pombreda 1y ago
:D
3.
by pombreda 1y ago
Yeah, this is messed up! But tell me when you cannot locate a correct PURL?
4.
by pombreda 1y ago
Actually, this is a locator alright. You can resolve a PURL to an actual package in an actual location.
5.
by pombreda 1y ago
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
6.
by pombreda 1y ago
We have a standard checksum "qualifier" at https://github.com/package-url/purl-spec/blob/main/PURL-SPEC... ... that would be the "hash" ... would this work?
7.
by pombreda 1y ago
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 s
8.
by pombreda 1y ago
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! pombredanne@aboutcode.org Or a comment on the issue or doc linked.
9.
by pombreda 1y ago
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 pombredanne@aboutcode.org
10.
by pombreda 1y ago
Can you tell a bit more? What is this? The OP article?
11.
by pombreda 1y ago
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?
12.
by pombreda 1y ago
> distinguish between "fully qualified" PURLs and "partial" PURLs. Can you tell a bit more? Not sure I get what you meant
13.
by 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 s
14.
by pombreda 1y ago
Yeah, I added generic as an escape hatch, but this should be only used by exception, e.g., a crutch. An abused crutch. Eventually, let's fix this first for C/C++: https://github.com/aboutcode-org/www.aboutcode
15.
by pombreda 1y ago
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.
16.
by pombreda 1y ago
Not sure I parse... do you mind to elaborate?
17.
by pombreda 1y ago
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 f
18.
by pombreda 1y ago
This is awesomely nice!
19.
by pombreda 1y ago
You wrote: > So to the more knowledgeable people out there, what is the PURL way of identifying a C++ library like that? That's a blind spot. This is a real problem for every as you rightfully explained. So I have been thinking a lo
20.
by pombreda 1y ago
Note that there should be a gitlab type as it is planned for: https://github.com/package-url/purl-spec/blob/a90ee02679afc3... gitlab and github do provide package-like discoverability. Do you have a pointer t
21.
by pombreda 1y ago
Not at all related. Just nicknamed the same.
22.
by pombreda 1y ago
We maintain the spec at https://github.com/package-url/purl-spec And the new thing, working towards making it a real standard with Ecma https://tc54.org/purl/ ... :)
23.
by pombreda 1y ago
Actually, I also used it when I first presented PURL at FOSDEM in 2018 https://archive.fosdem.org/2018/schedule/event/purl/ .... scroll the video at 9 minutes :] We need moooaaar standards, do we?
24.
by pombreda 1y ago
That's actually the best explanation I have seen in a long time! - in most cases, no guesses needed - you can use it in Cyclone, SPDX, and CSAF and still talk about the same package even if the format varies - CVE.org is considering it
25.
by pombreda 1y ago
This is not a valid PURL as it is missing a type, assuming you wanted golang here. It could be instead: pkg:golang/github.com%2Ffoobar%2Fgo-whatnot
26.
by pombreda 1y ago
Agreed. In hindsight, I always wonder if this was a good idea to have this split. At least the namespace is optional and required only certain package types
27.
by pombreda 1y ago
You want to avoid the "generic" type... and for docker containers and OCi images that's not needed.
28.
by pombreda 1y ago
Disclosure: I created that spec and we are working hard to clarify it and remove grey areas!
29.
by pombreda 1y ago
Encode the slash as explained in the clarified spec https://github.com/package-url/purl-spec/pull/453 :) We are working on further clarifying Golang which a bit problematic: there is really no name or namespa
30.
by pombreda 3y ago
You should not do FOSS if you do not want to make a gift, with few strings attached --if any. Use a proprietary license instead :]

More ›