You are viewing a plain text version of this content. The canonical link for it is here.
Posted to security-discuss@community.apache.org by Arnout Engelen <en...@apache.org> on 2023/03/28 11:11:43 UTC
Identifiers (purl, SWID) for Apache artifacts
Hello,
A challenge while sharing information about vulnerabilities is how to
"identify"/name software components. Of course there is good old
CPE[0], but a couple of file formats around security metadata, such as
OSV[1], SPDX[2] and CycloneDX[3], allow identifying packages by their
'purl'[4], 'SWID'[5] and/or ecosystem-specific identifiers.
While the dust hasn't settled on which of those formats will 'take
off', and we don't need to 'pick sides', it would be good to provide
some guidance on how those ID's should be used - we've already seen
one 3rd-party project[6] 'make up' identifiers in the apache
namespace, which rather defeats the purpose.
For purl, a purl identifier contains a 'type' (like 'deb' or
'apache'), a 'namespace' and a 'name', and optionally a version and
qualifiers[7]. Each 'type' has its own rules on what those look like
(for example "pkg:deb/debian/apache2@2.4.54-1~deb11u1?arch=i386&distro=jessie"
for a Debian package).
In Apache we already have a kind of hierarchy where a PMC covers
multiple projects, and each project can publish a number of artifacts.
At first glance it would make sense to document how to 'encode' that
into the Purl format, but in practice that seems to lead to rather
contrived names. I think it might be better to just have a small
'registry' of names under the Apache type, and allow each PMC/project
to document their preferred identifiers there, validating against
naming conflicts.
This could be as simple as a JSON file in a git repository somewhere,
making it relatively easy to integrate into our CVE tool, the upcoming
artifact platform and 3rd-party tools. Does anyone have thoughts on
this?
Kind regards,
Arnout
[0] https://nvd.nist.gov/products/cpe
[1] https://ossf.github.io/osv-schema/
[2] https://spdx.github.io/spdx-spec/v2.3/external-repository-identifiers/
[3] https://github.com/CycloneDX/specification/blob/master/schema/bom-1.4.xsd#L319
[4] https://github.com/package-url/purl-spec
[5] https://csrc.nist.gov/Projects/Software-Identification-SWID
[6] https://public.vulnerablecode.io/vulnerabilities/VCID-xsdu-9jb4-aaas
[7] https://github.com/package-url/purl-spec/blob/master/PURL-TYPES.rst
---------------------------------------------------------------------
To unsubscribe, e-mail: security-discuss-unsubscribe@community.apache.org
For additional commands, e-mail: security-discuss-help@community.apache.org
Re: Identifiers (purl, SWID) for Apache artifacts
Posted by Dirk-Willem van Gulik <di...@webweaving.org>.
> On 28 Mar 2023, at 14:46, sebb <se...@gmail.com> wrote:
>
> On Tue, 28 Mar 2023 at 12:42, Dirk-Willem van Gulik
> <di...@webweaving.org> wrote:
>>
>>
>> On 28 Mar 2023, at 13:11, Arnout Engelen <en...@apache.org> wrote:
>>
>>> In Apache we already have a kind of hierarchy where a PMC covers
>>> multiple projects, and each project can publish a number of artifacts.
>>> At first glance it would make sense to document how to 'encode' that
>>
>> As we currently defacto assume that any PCM gets a domain such as <pmc-name>.apache.org - with a human oriented website at https://pmc-name.apache.org/ associated - I would guess that org.apache.<pmc-name> or the FQDN is a good start for any PMC. As we're likely to keep that namespace free of clashes - even over very long periods of time.
>>
>> Now a lot of PMCs just have one `product' -- often with the same name.
>>
>> So perhaps a simple rule of that remove any consecutive duplicates would be a good start. Although ISO/IEC 19770-2:2015 and the IETF work on a SWID do sort of assume you do not do exactly that (they assume a regid that way separate from product identifier AFAIU).
>>
>> Having incubator prefixes `invalidate' as they become TLP's is not that big a loss.
>
> What about TLP renames?
Well - I would imagine* that we generally do this forward- and would find it very acceptable that a (vulnerability in an) old package retains its 'old' TLP name; while more recent vulnerabilities get a new name ? Or am I missing something ?
Dw.
*) I am trying to avoid getting into https://www.rfc-editor.org/rfc/rfc3406 and https://www.rfc-editor.org/rfc/rfc2483 and https://www.ietf.org/rfc/rfc3404.txt
Re: Identifiers (purl, SWID) for Apache artifacts
Posted by sebb <se...@gmail.com>.
On Tue, 28 Mar 2023 at 12:42, Dirk-Willem van Gulik
<di...@webweaving.org> wrote:
>
>
> On 28 Mar 2023, at 13:11, Arnout Engelen <en...@apache.org> wrote:
>
> > In Apache we already have a kind of hierarchy where a PMC covers
> > multiple projects, and each project can publish a number of artifacts.
> > At first glance it would make sense to document how to 'encode' that
>
> As we currently defacto assume that any PCM gets a domain such as <pmc-name>.apache.org - with a human oriented website at https://pmc-name.apache.org/ associated - I would guess that org.apache.<pmc-name> or the FQDN is a good start for any PMC. As we're likely to keep that namespace free of clashes - even over very long periods of time.
>
> Now a lot of PMCs just have one `product' -- often with the same name.
>
> So perhaps a simple rule of that remove any consecutive duplicates would be a good start. Although ISO/IEC 19770-2:2015 and the IETF work on a SWID do sort of assume you do not do exactly that (they assume a regid that way separate from product identifier AFAIU).
>
> Having incubator prefixes `invalidate' as they become TLP's is not that big a loss.
What about TLP renames?
> Dw.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: security-discuss-unsubscribe@community.apache.org
> For additional commands, e-mail: security-discuss-help@community.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: security-discuss-unsubscribe@community.apache.org
For additional commands, e-mail: security-discuss-help@community.apache.org
Re: Identifiers (purl, SWID) for Apache artifacts
Posted by Arnout Engelen <en...@apache.org>.
On Tue, Mar 28, 2023 at 4:33 PM Dirk-Willem van Gulik
<di...@webweaving.org> wrote:
> On 28 Mar 2023, at 16:06, Jarek Potiuk <ja...@potiuk.com> wrote:
> > Yeah. I think this is something we definitely need (I recall a recent
> > discussion about it with Arnout about providers and how they are
> > "identified" in CVES and such.
>
> So lets set a small policy here for the board to accept - below a strawman to shoot at.
>
> WHEREAS, the Board of Directors deems it to be in the best interests of the Foundation and consistent with the Foundation's purpose to maintain a well managed name space for PMCs in general and for the purposes of uniquely identifying software releases and vulnerabilities uniquely over long periods of time;
>
> NOW, THEREFORE, BE IT RESOLVED, that the Apache Software Foundation naming policy is as follows:
>
> == Software Identifying and Naming policy of the ASF
'Identification'?
> This policy clarifies the nature, scope and purpose of the ASF naming conventions:
>
> 1) Software artefacts of the foundation can be assigned an identifier. This identifier consists of a ASF specific prefix (asf), followed by the project name and followed by the software or product name. Separated by a '/'. Optionally followed by a '#' and a (semantic) version number.
>
> e.g. asf/airflow/providers-airbyte or asf/airflow/airflow-core#2.5.2
As there are PMC's that span several projects, "project name" looks a
bit confusing here. Perhaps we should change the ordering of the
points, and first introduce the 'project name' (now under '2') before
introducing the software identifiers that use it?
Should we call out explicitly that for the 'main' product of a PMC,
the name does not need to be repeated, so "asf/httpd#2.4.54" would be
acceptable?
The identifier above is neither a purl nor a SWID tagId. The idea
would be to define a mapping between the ASF identifiers and such
formats, right?
I think software identifiers should be allowed to be fine-grained -
for example, it would make sense to refer to the source distribution
of Cassandra with a different identifier than the binary distribution,
as the binary distribution also contains 3rd-party dependency jars. I
guess we could simply use a new name for that (e.g.
'asf/cassandra#4.1.0' and 'asf/cassandra/cassandra-bin#4.1.0'). I
wonder if it would make sense to allow for 'qualifiers' like purl
does. Then the above could be 'asf/cassandra#4.1.0' and
'asf/cassandra?packaging=bin#4.1.0', for example. They might still
have to be 'flattenable' when mapped to SWID, though.
> 2) All foundation projects (including those in the incubator) shall have a US-ASCII, case insensitive name, expressed in lowercase consisting of the letters 'a'-'z', the numbers '0'-'9' and the hyphen '-' of at least 2 and no more than 24 characters.
>
> For existing projects - this label will be the current apache.org <http://apache.org/> subdomain string. E.g. https://airflow.apache.org/
>
> 2) All names shall be unique (including those in the incubator) and from hereon part of the initial Establish board decision. No (historic) name shall re-used. A change requires board approval.
>
> 3) The PMC is responsible for managing the projects namespace as it sees fit. Any labels it assigns are subject to the same alpha-numeric and length constraints as the project name.
>
> For existing product/software artefacts the svn/git directory name will generally be used.
>
> The responsibility for this policy is with the President. The president shall direct the Security team to maintain a list of these unique identifiers and to maintain documentation and implementation guidance.
Sounds good to me
Arnout
---------------------------------------------------------------------
To unsubscribe, e-mail: security-discuss-unsubscribe@community.apache.org
For additional commands, e-mail: security-discuss-help@community.apache.org
Re: Identifiers (purl, SWID) for Apache artifacts
Posted by sebb <se...@gmail.com>.
Note that podling mailing lists no longer include an incubator prefix
or suffix etc.
AFAIK, the incubator path part is only added (and then not always) for websites.
On Tue, 28 Mar 2023 at 15:33, Dirk-Willem van Gulik
<di...@webweaving.org> wrote:
>
> On 28 Mar 2023, at 16:06, Jarek Potiuk <ja...@potiuk.com> wrote:
>
> > Yeah. I think this is something we definitely need (I recall a recent
> > discussion about it with Arnout about providers and how they are
> > "identified" in CVES and such.
>
> So lets set a small policy here for the board to accept - below a strawman to shoot at.
>
> Dw.
>
> WHEREAS, the Board of Directors deems it to be in the best interests of the Foundation and consistent with the Foundation's purpose to maintain a well managed name space for PMCs in general and for the purposes of uniquely identifying software releases and vulnerabilities uniquely over long periods of time;
>
> NOW, THEREFORE, BE IT RESOLVED, that the Apache Software Foundation naming policy is as follows:
>
> == Software Identifying and Naming policy of the ASF
>
> This policy clarifies the nature, scope and purpose of the ASF naming conventions:
>
> 1) Software artefacts of the foundation can be assigned an identifier. This identifier consists of a ASF specific prefix (asf), followed by the project name and followed by the software or product name. Separated by a '/'. Optionally followed by a '#' and a (semantic) version number.
>
> e.g. asf/airflow/providers-airbyte or asf/airflow/airflow-core#2.5.2
>
> 2) All foundation projects (including those in the incubator) shall have a US-ASCII, case insensitive name, expressed in lowercase consisting of the letters 'a'-'z', the numbers '0'-'9' and the hyphen '-' of at least 2 and no more than 24 characters.
>
> For existing projects - this label will be the current apache.org <http://apache.org/> subdomain string. E.g. https://airflow.apache.org/
>
> 2) All names shall be unique (including those in the incubator) and from hereon part of the initial Establish board decision. No (historic) name shall re-used. A change requires board approval.
>
> 3) The PMC is responsible for managing the projects namespace as it sees fit. Any labels it assigns are subject to the same alpha-nummeric and length constraints as the project name.
>
> For existing product/software artefacts the svn/git directory name will generally be used.
>
> The responsibility for this policy is with the President. The president shall direct the Security team to maintain a list of these unique identifiers and to maintain documentation and implementation guidenace.
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: security-discuss-unsubscribe@community.apache.org
For additional commands, e-mail: security-discuss-help@community.apache.org
Re: Identifiers (purl, SWID) for Apache artifacts
Posted by Jarek Potiuk <ja...@potiuk.com>.
+1. Works for me. Thanks for nicely interleaving the lawspeak with the
really important stuff :)
J.
On Tue, Mar 28, 2023 at 4:33 PM Dirk-Willem van Gulik
<di...@webweaving.org> wrote:
>
> On 28 Mar 2023, at 16:06, Jarek Potiuk <ja...@potiuk.com> wrote:
>
> > Yeah. I think this is something we definitely need (I recall a recent
> > discussion about it with Arnout about providers and how they are
> > "identified" in CVES and such.
>
> So lets set a small policy here for the board to accept - below a strawman to shoot at.
>
> Dw.
>
> WHEREAS, the Board of Directors deems it to be in the best interests of the Foundation and consistent with the Foundation's purpose to maintain a well managed name space for PMCs in general and for the purposes of uniquely identifying software releases and vulnerabilities uniquely over long periods of time;
>
> NOW, THEREFORE, BE IT RESOLVED, that the Apache Software Foundation naming policy is as follows:
>
> == Software Identifying and Naming policy of the ASF
>
> This policy clarifies the nature, scope and purpose of the ASF naming conventions:
>
> 1) Software artefacts of the foundation can be assigned an identifier. This identifier consists of a ASF specific prefix (asf), followed by the project name and followed by the software or product name. Separated by a '/'. Optionally followed by a '#' and a (semantic) version number.
>
> e.g. asf/airflow/providers-airbyte or asf/airflow/airflow-core#2.5.2
>
> 2) All foundation projects (including those in the incubator) shall have a US-ASCII, case insensitive name, expressed in lowercase consisting of the letters 'a'-'z', the numbers '0'-'9' and the hyphen '-' of at least 2 and no more than 24 characters.
>
> For existing projects - this label will be the current apache.org <http://apache.org/> subdomain string. E.g. https://airflow.apache.org/
>
> 2) All names shall be unique (including those in the incubator) and from hereon part of the initial Establish board decision. No (historic) name shall re-used. A change requires board approval.
>
> 3) The PMC is responsible for managing the projects namespace as it sees fit. Any labels it assigns are subject to the same alpha-nummeric and length constraints as the project name.
>
> For existing product/software artefacts the svn/git directory name will generally be used.
>
> The responsibility for this policy is with the President. The president shall direct the Security team to maintain a list of these unique identifiers and to maintain documentation and implementation guidenace.
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: security-discuss-unsubscribe@community.apache.org
For additional commands, e-mail: security-discuss-help@community.apache.org
Re: Identifiers (purl, SWID) for Apache artifacts
Posted by Dirk-Willem van Gulik <di...@webweaving.org>.
On 28 Mar 2023, at 16:06, Jarek Potiuk <ja...@potiuk.com> wrote:
> Yeah. I think this is something we definitely need (I recall a recent
> discussion about it with Arnout about providers and how they are
> "identified" in CVES and such.
So lets set a small policy here for the board to accept - below a strawman to shoot at.
Dw.
WHEREAS, the Board of Directors deems it to be in the best interests of the Foundation and consistent with the Foundation's purpose to maintain a well managed name space for PMCs in general and for the purposes of uniquely identifying software releases and vulnerabilities uniquely over long periods of time;
NOW, THEREFORE, BE IT RESOLVED, that the Apache Software Foundation naming policy is as follows:
== Software Identifying and Naming policy of the ASF
This policy clarifies the nature, scope and purpose of the ASF naming conventions:
1) Software artefacts of the foundation can be assigned an identifier. This identifier consists of a ASF specific prefix (asf), followed by the project name and followed by the software or product name. Separated by a '/'. Optionally followed by a '#' and a (semantic) version number.
e.g. asf/airflow/providers-airbyte or asf/airflow/airflow-core#2.5.2
2) All foundation projects (including those in the incubator) shall have a US-ASCII, case insensitive name, expressed in lowercase consisting of the letters 'a'-'z', the numbers '0'-'9' and the hyphen '-' of at least 2 and no more than 24 characters.
For existing projects - this label will be the current apache.org <http://apache.org/> subdomain string. E.g. https://airflow.apache.org/
2) All names shall be unique (including those in the incubator) and from hereon part of the initial Establish board decision. No (historic) name shall re-used. A change requires board approval.
3) The PMC is responsible for managing the projects namespace as it sees fit. Any labels it assigns are subject to the same alpha-nummeric and length constraints as the project name.
For existing product/software artefacts the svn/git directory name will generally be used.
The responsibility for this policy is with the President. The president shall direct the Security team to maintain a list of these unique identifiers and to maintain documentation and implementation guidenace.
Re: Identifiers (purl, SWID) for Apache artifacts
Posted by Jarek Potiuk <ja...@potiuk.com>.
Yeah. I think this is something we definitely need (I recall a recent
discussion about it with Arnout about providers and how they are
"identified" in CVES and such.
> .....
> > Some other examples: 'pkg:apache/commons/io',
> > 'pkg:apache/xmlgraphics/batik', 'pkg:apache/airflow/providers-airbyte'
> > - looks OK to me?
>
> Aye - looks OK. And more than that - I would be perfectly willing to let every PMC manage their own house, their namespace in ways that work with the community.
Yep. The 'pkg:apache/airflow/providers-airbyte' is a good example. And
I perfectly agree with DirkWillem on self-managing the space by the
PMC. We really need "Apache/pmc" namespace standardized on the Apache
level - the rest should be delegated.
Though I'd likely start with `pkg:asf` out of caution - since this is
a forward-looking thing. It's just an ID meant to be consumed
automatically, so we are not likely bound by the "apache" familiarity.
Maybe we should just agree, that it should be for example a valid URI.
Possibly there are already some efforts to standardize the form of it
i have not (yet) looked in detail at various SPDX/SBOM etc. but I
imagine this is not a "new" subject - I vaguely recall seeing just a
"URI" as such requirement - maybe there are even some recommendations
to use one of the RFCS DW posted :)
> >> Having incubator prefixes `invalidate' as they become TLP's is not that big a loss.
> >
> > I agree, though I could also see dropping the incubator prefix from
> > the purl/SWID - or would that create problems?
I am not sure if we have to distinguish incubating from incubated
projects in the unique ID. This is just a unique identifier - it bears
no meaning (I think) whether the project has already incubated or not.
Maybe we don't have to add significance of incubation to the
identifier?
> May be a good idea; though I am not sure if we are that good yet in policing the names already. One for the incubator to answer (but I cannot think of a mistake we've made there).
> > For TLP renames, I agree it would make sense for old statements to
> > keep referring to the old name. If we keep a registry then we could
> > introduce a 'deprecated-by' field or something similar, so tools could
> > treat the old and the new name as synonyms.
I believe the standard of publishing this information (if they are
well written) should be able to accomodate to changes - we might want
to keep it in our records, but possibly the PMC in question would
simply make sure to add "formerly: ble"
>
> Ack !
>
> Dw.
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: security-discuss-unsubscribe@community.apache.org
> For additional commands, e-mail: security-discuss-help@community.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: security-discuss-unsubscribe@community.apache.org
For additional commands, e-mail: security-discuss-help@community.apache.org
Re: Identifiers (purl, SWID) for Apache artifacts
Posted by Gilles Sadowski <gi...@gmail.com>.
Hi.
Le mar. 28 mars 2023 à 15:53, Dirk-Willem van Gulik
<di...@webweaving.org> a écrit :
>
> [...]
> .....
> > Some other examples: 'pkg:apache/commons/io',
> > 'pkg:apache/xmlgraphics/batik', 'pkg:apache/airflow/providers-airbyte'
> > - looks OK to me?
>
> Aye - looks OK. And more than that - I would be perfectly willing to let every PMC manage their own house, their namespace in ways that work with the community.
>
> So from a security perspective - we expect you to have a prefix org.apache.<PMCname> -- and expect the PMC to do things 'down' from there.
Wouldn't it open the "opportunity" to let several get their own
wrong wheel?
Regards,
Gilles
>
> [...]
---------------------------------------------------------------------
To unsubscribe, e-mail: security-discuss-unsubscribe@community.apache.org
For additional commands, e-mail: security-discuss-help@community.apache.org
Re: Identifiers (purl, SWID) for Apache artifacts
Posted by Dirk-Willem van Gulik <di...@webweaving.org>.
On 28 Mar 2023, at 15:27, Arnout Engelen <en...@apache.org> wrote:
> On Tue, Mar 28, 2023 at 1:42 PM Dirk-Willem van Gulik <di...@webweaving.org> wrote:
>> On 28 Mar 2023, at 13:11, Arnout Engelen <en...@apache.org> wrote:
>>> In Apache we already have a kind of hierarchy where a PMC covers
>>> multiple projects, and each project can publish a number of artifacts.
>>> At first glance it would make sense to document how to 'encode' that
>>
>> As we currently defacto assume that any PCM gets a domain such as <pmc-name>.apache.org - with a human oriented website at https://pmc-name.apache.org/ associated - I would guess that org.apache.<pmc-name> or the FQDN is a good start for any PMC. As we're likely to keep that namespace free of clashes - even over very long periods of time.
>>
>> Now a lot of PMCs just have one `product' -- often with the same name.
>>
>> So perhaps a simple rule of that remove any consecutive duplicates would be a good start.
>
> Starting with the PMC name definitely makes sense. After that it gets
> more messy though: as one example, the HTTP Server PMC (httpd) has two
> projects: 'http_server' and 'mod_ftp', but also publishes for example
> 'libapreq', which is not an 'Apache Project' (AFAICS?) but still is
> something we publish artifacts for. I guess that 'falls under'
.....
> Some other examples: 'pkg:apache/commons/io',
> 'pkg:apache/xmlgraphics/batik', 'pkg:apache/airflow/providers-airbyte'
> - looks OK to me?
Aye - looks OK. And more than that - I would be perfectly willing to let every PMC manage their own house, their namespace in ways that work with the community.
So from a security perspective - we expect you to have a prefix org.apache.<PMCname> -- and expect the PMC to do things 'down' from there.
>> Although ISO/IEC 19770-2:2015 and the IETF work on a SWID do sort of assume you do not do exactly that (they assume a regid that way separate from product identifier AFAIU).
>
> I haven't dug into SWID properly yet, but my impression is perhaps we
> should have 'apache.org' as one big 'regid', and distinguish between
> different projects/artifacts in the 'tagId' (which AFAICS must still
> be globally unique and would start with 'org.apache')
That is indeed their line of thought (or a DUNS number, etc).
>> Having incubator prefixes `invalidate' as they become TLP's is not that big a loss.
>
> I agree, though I could also see dropping the incubator prefix from
> the purl/SWID - or would that create problems?
May be a good idea; though I am not sure if we are that good yet in policing the names already. One for the incubator to answer (but I cannot think of a mistake we've made there).
> For TLP renames, I agree it would make sense for old statements to
> keep referring to the old name. If we keep a registry then we could
> introduce a 'deprecated-by' field or something similar, so tools could
> treat the old and the new name as synonyms.
Ack !
Dw.
---------------------------------------------------------------------
To unsubscribe, e-mail: security-discuss-unsubscribe@community.apache.org
For additional commands, e-mail: security-discuss-help@community.apache.org
Re: Identifiers (purl, SWID) for Apache artifacts
Posted by Arnout Engelen <en...@apache.org>.
On Tue, Mar 28, 2023 at 1:42 PM Dirk-Willem van Gulik
<di...@webweaving.org> wrote:
> On 28 Mar 2023, at 13:11, Arnout Engelen <en...@apache.org> wrote:
> > In Apache we already have a kind of hierarchy where a PMC covers
> > multiple projects, and each project can publish a number of artifacts.
> > At first glance it would make sense to document how to 'encode' that
>
> As we currently defacto assume that any PCM gets a domain such as <pmc-name>.apache.org - with a human oriented website at https://pmc-name.apache.org/ associated - I would guess that org.apache.<pmc-name> or the FQDN is a good start for any PMC. As we're likely to keep that namespace free of clashes - even over very long periods of time.
>
> Now a lot of PMCs just have one `product' -- often with the same name.
>
> So perhaps a simple rule of that remove any consecutive duplicates would be a good start.
Starting with the PMC name definitely makes sense. After that it gets
more messy though: as one example, the HTTP Server PMC (httpd) has two
projects: 'http_server' and 'mod_ftp', but also publishes for example
'libapreq', which is not an 'Apache Project' (AFAICS?) but still is
something we publish artifacts for. I guess that 'falls under'
'http_server', but encoding that in the name seems messy. so just
using 'pkg:apache/httpd' (for the main software), 'pkg:apache/mod_ftp'
and 'pkg:apache/httpd/libapreq' would make sense to me even when that
doesn't strictly encode the PMC/project/artifact hierarchy.
Some other examples: 'pkg:apache/commons/io',
'pkg:apache/xmlgraphics/batik', 'pkg:apache/airflow/providers-airbyte'
- looks OK to me?
For components that are published in different 'forms' it seems we
could use the qualifiers, like "?packaging=combined", or new names,
like 'foo-installer', leading to more opportunity for ambiguity -
which is why introducing some 'source of truth' seems attractive to me
;)
> Although ISO/IEC 19770-2:2015 and the IETF work on a SWID do sort of assume you do not do exactly that (they assume a regid that way separate from product identifier AFAIU).
I haven't dug into SWID properly yet, but my impression is perhaps we
should have 'apache.org' as one big 'regid', and distinguish between
different projects/artifacts in the 'tagId' (which AFAICS must still
be globally unique and would start with 'org.apache')
> Having incubator prefixes `invalidate' as they become TLP's is not that big a loss.
I agree, though I could also see dropping the incubator prefix from
the purl/SWID - or would that create problems?
For TLP renames, I agree it would make sense for old statements to
keep referring to the old name. If we keep a registry then we could
introduce a 'deprecated-by' field or something similar, so tools could
treat the old and the new name as synonyms.
Kind regards,
Arnout
---------------------------------------------------------------------
To unsubscribe, e-mail: security-discuss-unsubscribe@community.apache.org
For additional commands, e-mail: security-discuss-help@community.apache.org
Re: Identifiers (purl, SWID) for Apache artifacts
Posted by Dirk-Willem van Gulik <di...@webweaving.org>.
On 28 Mar 2023, at 13:11, Arnout Engelen <en...@apache.org> wrote:
> In Apache we already have a kind of hierarchy where a PMC covers
> multiple projects, and each project can publish a number of artifacts.
> At first glance it would make sense to document how to 'encode' that
As we currently defacto assume that any PCM gets a domain such as <pmc-name>.apache.org - with a human oriented website at https://pmc-name.apache.org/ associated - I would guess that org.apache.<pmc-name> or the FQDN is a good start for any PMC. As we're likely to keep that namespace free of clashes - even over very long periods of time.
Now a lot of PMCs just have one `product' -- often with the same name.
So perhaps a simple rule of that remove any consecutive duplicates would be a good start. Although ISO/IEC 19770-2:2015 and the IETF work on a SWID do sort of assume you do not do exactly that (they assume a regid that way separate from product identifier AFAIU).
Having incubator prefixes `invalidate' as they become TLP's is not that big a loss.
Dw.
---------------------------------------------------------------------
To unsubscribe, e-mail: security-discuss-unsubscribe@community.apache.org
For additional commands, e-mail: security-discuss-help@community.apache.org