Consider adopting package-url for external package references #53
Comments
|
@pombredanne purl is a pretty well-known service for permanent URLs (purl.org), run by the Internet Archive. |
|
On Thu, Dec 07, 2017 at 03:36:40PM -0800, Alexios Zavras (zvr) wrote:
Consider changing the name...
It looks like Package URLs don't contain host information [1].
Perhaps they should be Package URIs (puri [2])?
[1]: https://en.wikipedia.org/wiki/Puri_%28food%29
[2]: https://github.com/package-url/purl-spec/blame/d250235b02d0fba8a3f9a8977e979db43ceb33da/README.rst#L93-L95
|
|
After reading over the Package URL spec a few times, my initial impression is that the real problem is that package-manager and version-control authors haven't gone through the trouble to register URI schemes (although there is a provisional registration for |
|
@wking |
|
@wking you wote:
You can read the comments from URLs authorities in package-url/purl-spec#9 .... they have no objections there. And FWIW, this is really a locator alright even though there is no "Authority" component. |
So we agree on just dropping appendix VI and its one reference from the spec? Folks who want to use URIs to reference external packages can discover schemes (possibly eventually including |
|
I think that external references are a good thing of themselves, but detailing the way they should be specified as it has been done could be improved for sure. |
|
Key is going to be to make sure the references to packages are parseable and well specified - whats there has been understood to not be complete but a place to build from. There are two main use cases for making external references - for security artifacts (CPEs, possibly SWIDs) and to package managers. There were some arguing strongly they should all just be external references, but my preference would be to call security out independently, and then align in with the purl/puri/.. for external references, as the package-url doesn't handle the CPEs. At any rate a good topic to revisit. |
This section has never been particularly tight. For example, the old: `<type>` is an [idstring] that is defined in Appendix. was probably intended to reference the old Appendix VII (removed by the previous commit). This commit ties them strictly to generic URIs (see discussion in [1]). That breaks compatibility with the old form, but since the old form was unclear, I think that's ok. The cpe entries are already URIs in their own right, although they aren't registered with IANA [2]. You can resolve them via [3] (e.g. [4]). There are also other currently-unregistered schemes for referencing packages, e.g. [5]. But managing all of that complexity isn't something that SPDX should handle. Instead, folks interested in providing stable packaging and security references should work on registering their URIs with IANA (or on establishing them in the SPDX ecosystem despite their not being registered). [1]: spdx#53 [2]: https://www.iana.org/assignments/uri-schemes/uri-schemes.xhtml [3]: https://nvd.nist.gov/products/cpe/search [4]: https://nvd.nist.gov/vuln/search/results?adv_search=true&cpe=cpe%3A2.3%3Aa%3Apivotal_software%3Aspring_framework%3A4.1.0%3A%2A%3A%2A%3A%2A%3A%2A%3A%2A%3A%2A%3A%2A [5]: https://github.com/package-url/purl-spec
But why would it be SPDX's job to register schemes? I've floated a potential approach in #54 that just makes these references URIs (preserving the category tagging). Then it's up to schema designers like package-url/purl-spec to get their schemes registered with the IANA (or to get their schemes into the SPDX ecosystem without IANA registration). I don't see a need for SPDX to be a second-tier URI-scheme registrar, with the IANA already filling that position for us. |
This section has never been particularly tight. For example, the old: `<type>` is an [idstring] that is defined in Appendix. was probably intended to reference the old Appendix VII (removed by the previous commit). This commit ties them strictly to generic URIs (see discussion in [1]). That breaks compatibility with the old form, but since the old form was unclear, I think that's ok. The cpe entries are already URIs in their own right, although they aren't registered with IANA [2]. You can resolve them via [3] (e.g. [4]). There are also other currently-unregistered schemes for referencing packages, e.g. [5]. But managing all of that complexity isn't something that SPDX should handle. Instead, folks interested in providing stable packaging and security references should work on registering their URIs with IANA (or on establishing them in the SPDX ecosystem despite their not being registered). [1]: spdx#53 [2]: https://www.iana.org/assignments/uri-schemes/uri-schemes.xhtml [3]: https://nvd.nist.gov/products/cpe/search [4]: https://nvd.nist.gov/vuln/search/results?adv_search=true&cpe=cpe%3A2.3%3Aa%3Apivotal_software%3Aspring_framework%3A4.1.0%3A%2A%3A%2A%3A%2A%3A%2A%3A%2A%3A%2A%3A%2A [5]: https://github.com/package-url/purl-spec
|
re:
Did anyone say we would/should register schemes? And FWIW, for purl we are honing on a single |
Maybe I was reading tooo much into "align in with the purl/puri". So is #54 the direction we're all thinking about? |
|
We should discuss in tech call. It will require deprecating some features and splitting out security, but this is a better direction and will align with other open source projects handling these topics (Grafeas). |
tsteenbe
changed the title
purl package urls for external package references
tsteenbe
changed the title
This section has never been particularly tight. For example, the old: `<type>` is an [idstring] that is defined in Appendix. was probably intended to reference the old Appendix VII (removed by the previous commit). This commit ties them strictly to generic URIs (see discussion in [1]). That breaks compatibility with the old form, but since the old form was unclear, I think that's ok. The cpe entries are already URIs in their own right, although they aren't registered with IANA [2]. You can resolve them via [3] (e.g. [4]). There are also other currently-unregistered schemes for referencing packages, e.g. [5]. But managing all of that complexity isn't something that SPDX should handle. Instead, folks interested in providing stable packaging and security references should work on registering their URIs with IANA (or on establishing them in the SPDX ecosystem despite their not being registered). This commit also tightens the relationship between category values and their rdf:resource URIs. And it removes "OTHER" and instead encourages authors to define their own category name (and associated rdf:resource URI). [1]: spdx#53 [2]: https://www.iana.org/assignments/uri-schemes/uri-schemes.xhtml [3]: https://nvd.nist.gov/products/cpe/search [4]: https://nvd.nist.gov/vuln/search/results?adv_search=true&cpe=cpe%3A2.3%3Aa%3Apivotal_software%3Aspring_framework%3A4.1.0%3A%2A%3A%2A%3A%2A%3A%2A%3A%2A%3A%2A%3A%2A [5]: https://github.com/package-url/purl-spec
This section has never been particularly tight. For example, the old: `<type>` is an [idstring] that is defined in Appendix. was probably intended to reference the old Appendix VII (removed by the previous commit). This commit ties them strictly to generic URIs (see discussion in [1]). That breaks compatibility with the old form, but since the old form was unclear, I think that's ok. The cpe entries are already URIs in their own right, although they aren't registered with IANA [2]. You can resolve them via [3] (e.g. [4]). There are also other currently-unregistered schemes for referencing packages, e.g. [5]. But managing all of that complexity isn't something that SPDX should handle. Instead, folks interested in providing stable packaging and security references should work on registering their URIs with IANA (or on establishing them in the SPDX ecosystem despite their not being registered). This commit also tightens the relationship between category values and their rdf:resource URIs. And it removes "OTHER" and instead encourages authors to define their own category name (and associated rdf:resource URI). [1]: spdx#53 [2]: https://www.iana.org/assignments/uri-schemes/uri-schemes.xhtml [3]: https://nvd.nist.gov/products/cpe/search [4]: https://nvd.nist.gov/vuln/search/results?adv_search=true&cpe=cpe%3A2.3%3Aa%3Apivotal_software%3Aspring_framework%3A4.1.0%3A%2A%3A%2A%3A%2A%3A%2A%3A%2A%3A%2A%3A%2A [5]: https://github.com/package-url/purl-spec
This section has never been particularly tight. For example, the old: `<type>` is an [idstring] that is defined in Appendix. was probably intended to reference the old Appendix VII (removed by the previous commit). This commit ties them strictly to generic URIs (see discussion in [1]). That breaks compatibility with the old form, but since the old form was unclear, I think that's ok. The cpe entries are already URIs in their own right, although they aren't registered with IANA [2]. You can resolve them via [3] (e.g. [4]). There are also other currently-unregistered schemes for referencing packages, e.g. [5]. But managing all of that complexity isn't something that SPDX should handle. Instead, folks interested in providing stable packaging and security references should work on registering their URIs with IANA (or on establishing them in the SPDX ecosystem despite their not being registered). This commit also tightens the relationship between category values and their rdf:resource URIs. And it removes "OTHER" and instead encourages authors to define their own category name (and associated rdf:resource URI). [1]: spdx#53 [2]: https://www.iana.org/assignments/uri-schemes/uri-schemes.xhtml [3]: https://nvd.nist.gov/products/cpe/search [4]: https://nvd.nist.gov/vuln/search/results?adv_search=true&cpe=cpe%3A2.3%3Aa%3Apivotal_software%3Aspring_framework%3A4.1.0%3A%2A%3A%2A%3A%2A%3A%2A%3A%2A%3A%2A%3A%2A [5]: https://github.com/package-url/purl-spec
This section has never been particularly tight. For example, the old: `<type>` is an [idstring] that is defined in Appendix. was probably intended to reference the old Appendix VII (removed by the previous commit). This commit ties them strictly to generic URIs (see discussion in [1]). That breaks compatibility with the old form, but since the old form was unclear, I think that's ok. The cpe entries are already URIs in their own right, although they aren't registered with IANA [2]. You can resolve them via [3] (e.g. [4]). There are also other currently-unregistered schemes for referencing packages, e.g. [5]. But managing all of that complexity isn't something that SPDX should handle. Instead, folks interested in providing stable packaging and security references should work on registering their URIs with IANA (or on establishing them in the SPDX ecosystem despite their not being registered). This commit also tightens the relationship between category values and their rdf:resource URIs. And it removes "OTHER" and instead encourages authors to define their own category name (and associated rdf:resource URI). [1]: spdx#53 [2]: https://www.iana.org/assignments/uri-schemes/uri-schemes.xhtml [3]: https://nvd.nist.gov/products/cpe/search [4]: https://nvd.nist.gov/vuln/search/results?adv_search=true&cpe=cpe%3A2.3%3Aa%3Apivotal_software%3Aspring_framework%3A4.1.0%3A%2A%3A%2A%3A%2A%3A%2A%3A%2A%3A%2A%3A%2A [5]: https://github.com/package-url/purl-spec
|
FYI, I presented purl at FOSDEM: https://fosdem.org/2018/schedule/event/purl/ |
|
During tech team call today this was discussed. |
|
On Tue, Feb 20, 2018 at 06:44:45PM +0000, Kate Stewart wrote:
There was general agreement to move this in as an optional field for
2.2, once the specification has been stabilized and adopted by the
other stakeholders. Plan will be to snapshot the specification
information, and add it as an optional field in the text of the SPDX
specification. A table with the already defined package managers
will be added.
Was there any discussion of the approach taken by #54 to resolve this
issue? I don't see a need to define URI schemes for these external
references, whether via the current External References or via
package-url. Once you have ExternalRef taking a URI, you can punt to
the IANA registry and/or unregistered URI-scheme specs, and there's no
need for the SPDX to bless particular schemes.
|
|
From SPDX tech call 6/5/2018: Request to review PR #54 to see if this satisfies this issue. |
|
I don't think we've reached consensus on abolishing "type", have we? Because that's what #54 seems to do. |
I'm intentionally removing it there, because I don't think it adds information beyond what is already contained in the URI. For example this change: - ExternalRef: SECURITY cpe23Type cpe:2.3:a:pivotal_software:spring_framework:4.1.0:*:*:*:*:*:*:*
+ ExternalRef: SECURITY cpe:2.3:a:pivotal_software:spring_framework:4.1.0:*:*:*:*:*:*:*has no need for a |
|
Type exists for a reason: to identify how to interpret the locator. Yes, you could conflate them into a single field, but if you wanted to, you could conflate the whole spec into a single field. The type and the locator have distinct meanings and hence they are distinct fields. |
I think For By requiring type qualifiers on top of the URI scheme, you basically break the well-supported URI approach and replace it with an SPDX specific typed-URI system. I think that's a lot of work (both for spec maintainers and tool maintainers) without an upside. Or is there an upside I'm missing? |
|
Discussed on tech call 6-12-2018: For 2.2, we need to be compatible. Abolishing type would create an incompatibility. We should consider this for 3.0. For 2.2, we would like to support package-url so we will need a different mechanism. Will pick up the discussion once @wking joins the tech call. We would also like to have @pombredanne . Propose discussing on 26 June 2018. |
|
Can we use type of "PURL" for the ones coming from that domain , and then reconcile the overlap between whole type issue in 3.0? |
|
Single string as identier is ok by Philippe as well as parse-able. |
|
If we use External Identifiers, must have 1 and only 1 of Category, Type, idstring Note: we need to update External Identifier TYPE to be case insesitive. Right now ambigous. Options discussed inclusion with Type: Preference is to use ID PURL - - as its shorter, based on discussion in call. Options would look like: Example PURLs: @pombredanne, @kestewart, @tsteenbe, @yevster, @goneall were in meeting for discussion and agree with above conclusion. |
|
Merged #152 |
https://github.com/package-url is an emerging grass root effort to design a simple and mostly universal package id and locator. This would be a much improved alternative to the partially defined https://github.com/spdx/spdx-spec/blob/cfa1b9d08903befdf03e669da6472707b7b60cb9/chapters/appendix-VI-external-repository-identifiers.md
The text was updated successfully, but these errors were encountered: