[Proposal] Adopt the "purl" package URL spec to identify software packages about grafeas

[R2wenD2]

Thanks @pombredanne I'll review and leave comments early next week.
I don't think this changes the much for Grafeas - would just require the API implementation to handle and validate the revised formats.

[lizrice]

The container image referencing in the purl spec looks good to me

[vbatts]

I don't intend to derail purl adoption. I think I've articulated my hesitation, which seems to be a general problem and not exclusive to purl. package-url/purl-spec#29

[vbatts]

So I'm now learning the extent of the work that has gone into SWID ISO 19770-2, despite the pay-wall barrier. I'm very glad that purl-spec is more open, but we might should consider that many deployments may have requirements to use SWID over purl.
Purl-spec has a FAQ about this, https://github.com/package-url/purl-spec/wiki/FAQ#why-not-using-the-iso-19770-2-spec-for-swid-tags-instead-of-a-purl which I don't disagree with. Red Hat has participated in the SWID review, and is also a part urging/pressuring Tagvault to open the SWID spec up more.

[pombredanne]

@R2wenD2 here we go as promised!

[pombredanne]

Thanks!

I don't think this changes the much for Grafeas - would just require the API implementation to handle and validate the revised formats.

Indeed, and that's part of the intent.

FWIW there is a mention of a Go implementation in progress on the PR at package-url/purl-spec#1 (comment)

[brianf]

Maven has a few more coordinates that can come into play in some instances: packaging and classifier. The typical ordering looks like this:
groupId:artifactId:(optional)packaging:(optional)classifier:version

While GAV may be sufficient for many cases, there will be times where some attestation needs to apply to one classifier and not another, or one package and not another. We should expand the spec to allow the optional inclusion of these extra fields.

ref: https://maven.apache.org/pom.html#Maven_Coordinates

[pombredanne]

@brianf yes Maven has these and these are not the norm as you pointed out quite rightly. The current Grafeas README does not handle these at all. They also in most case derive from the same source, hence for these they would be treated as optional qualifiers in https://github.com/package-url/purl-spec/tree/a21a9ecbab171fe06d1ac88843bc3721a42dbed0 and they would come as "query string" aka. purl qualifiers with this proposal:

maven for Maven JARs and related artifacts
- The default repository is maven.org
- The group id is the namespace and the artifact id is the name
- Known qualifiers keys are: classifier and packaging as defined in the POM documentation
- Examples:
`maven:org.apache.xmlgraphics/[email protected]`
`maven:org.apache.xmlgraphics/[email protected]?packaging=sources`

[pombredanne]

@brianf It would be awesome if you want to chime in on the purl spec btw. The initial and a tad messy PR is there package-url/purl-spec#1 and received comments from dpkg, nuget, spak, npm and several important package format maintainers and many others. Going forward a ticket is better.
Having a JVM implementation is also needed!

[brianf]

Is the intent of the purl spec to replace the one in the README? If not, how do they correlate?

[pombredanne]

@brianf that's the intent of this ticket to propose a replacement for the one of the README alright

[pombredanne]

The purl spec extends a bit beyond Grafeas as it also caters to other tools, DB and APIs such as libraries.io, victims, openshift analytics, aboutcode.org projects and a few more.

[pombredanne]

@lizrice Thank you for the valuable feedback!

[R2wenD2]

I think everyone is happy with this proposal, we'll just need to add the verification to the reference implementation and documentation.

[vbatts]

woof this purl conversation has gone wild while I was out! So to be clear, https://github.com/package-url/purl-spec is a recent discussion and not a widely agreed-upon and implemented spec, right?
I can follow the table, just want to make sure that it's a wider conversation.

[brianf]

If by recent / !wider you mean it's not widely implemented by tools, yes that's true. The conversation has been going since mid November and this seems to have good traction covering a large swath of packages out there. Certainly from my POV, this is the best attempt at defining this I've ever seen and think it fits perfectly into what Grafeas wants to be.

…

On Tue, Jan 2, 2018 at 4:12 PM, Vincent Batts ***@***.***> wrote: woof this purl conversation has gone wild while I was out! So to be clear, https://github.com/package-url/purl-spec is a recent discussion and not a widely agreed-upon and implemented spec, right? I can follow the table, just want to make sure that it's a wider conversation. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#65 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAD7CGVQmdZWylAuI84zaw3YCL88R7_tks5tGpvUgaJpZM4Qb6Er> .

[R2wenD2]

@vbatts Do you have reservations about purl? If so I'd love to hear them. We want some kind of standard format for grafeas, so I basically +1 everything that @brianf said above.

[vbatts]

On 03/01/18 16:56 +0000, R2wenD2 wrote: @vbatts Do you have reservations about purl? If so I'd love to hear them. We want some kind of standard format for grafeas, so I basically +1 everything that @brianf said above.

faced with inventing something yourself, and working with others, it's ideal to work together. Only reservation was just that it's not a widely embraced thing [yet].

[vbatts]

❤️

[R2wenD2]

No problem. I think its still something we want to do. At this point, I expect that purl adoption means updating docs as well as the API implementation to parse for it.

[R2wenD2]

Next steps here:

1. Update docs
2. Incorporate the purl checks into our reference implementation!

[pombredanne]

@vbatts Just back from FOSDEM where I presented this https://fosdem.org/2018/schedule/event/purl/ (video and deck are there)
There was a clear preference from most everyone there to use a single scheme prefix eg. pkg:npm:[email protected] such that this can be easily registered as an official RFC and many other good reasons so in this context we could have something like:
pkg:swid:<whatever is a swid> OR have a proper SWID URI or URL separately alright.
I wished SWID would not have been these walled garden centralized scheme, but that's not my battle to fight ;) Let's make a ticket on the purl side to have this included alright

[pombredanne]

I would like to attract your attention to this purl ticket package-url/purl-spec#9
... which eventually would mean that all purl would share a common pkg: URL prefix for many good reasons including invaluable feedback from @annevk and @mnot

Some impact here: this would mean that existing grafeas resource URIs would not be quasi-purlesque as-is because of this added prefix BUT it also means more flexibility to use other identification strings such as swid, cpe, etc in the same spot. Food for thoughts!

[vbatts]

@pombredanne there is further conversation going regarding SWID. I am thinking that the prefixing may help. Further this FAQ really ought to be updated from "avoid this"-like language. As one [private] conversation included:

I can understand the sentiment, but it is wrong in many respects. First, the
ISO specification is not for proprietary software. How can anyone come to
that conclusion. The C programming language is governed by ISO/IEC 9899:2011.
Does that mean that gcc is a proprietary compiler? I think not.

Having this distinguished prefixes, it'll let SWID do what it's intended for of specifying files (not just whole software packages, regardless of proprietary or FOSS), and purl can map collections/packages of software.

Make sense?