Re: [sw360-dev] Oldie but goldie: Component Identification

["Michael C. Jaeger" <mcj@xxxxxx>]

Hello,

I am not sure about your direction, my intention was to talk about a different problem here: it is not about delivering a unique idenfitier for a unique variant of a release of a component in sw360. It is just the proposal to use the names like "maven", "deb", "npm", ... from an existing list rather than generating a new one. 

Apart from that: the docker examples on seem to cover your concern:

https://github.com/package-url/purl-spec

Kind regards, Michael

PS. pasted from the link:

```
	• docker for Docker images

		• The default repository is https://hub.docker.com

		• The namespace is the registry/user/organization if present

		• The version should be the image id sha256 or a tag. Since tags can be moved, a sha256 image id is preferred.

		• Examples:

pkg:docker/cassandra@latest
pkg:docker/smartentry/debian@dc437cc87d10
pkg:docker/gcr.io/customer/dockerimage@sha256%3A244fd47e07d10

```





> On 11. Jan 2019, at 12:54, Maximilian Huber <maximilian.huber@xxxxxxxxxxx> wrote:
> 
> On Fr, 11. Jan 11:12, Kristan Johannes (INST-CSS/BSV-OS1) wrote:
>> We just define another external id "purl" which stores the purl.
> 
> Is the purl unique? Or is it like a classic URL and there are multiple
> representations of the same resource. Especially for docker, where the
> non-deterministic build yields different hashes. Or also the case where the same
> artifact is distributed over different tools (e.g. the zoo of tools for JS).
> 
> I think a release should at least have a list purls, and two releases are equal
> if at least one of them matches. This also means that non-matching purls do not
> imply that the artifacts are not equal.
> 
> In my opinion, if one knows coordinates and file-hashes of some artifact, one
> can generate a list of identifying features. And  some of these features could
> be encoded as a purl.
> 
> Best regards
> Maximilian
> 
> On Fr, 11. Jan 11:12, Kristan Johannes (INST-CSS/BSV-OS1) wrote:
>> Hi,
>> 
>> I am not one hundred percent sure what the actual proposal is. However, I
>> think it is generally a good idea to store the purl for a component. Shouldn't
>> this already work with our external id concept. We just define another
>> external id "purl" which stores the purl.
>> 
>> In antenna we had similar discussions about coordinates and introduced a
>> hierarchy of possible namings for components, from very generic ones, eg just
>> the filename, to specific ones like maven coordinates. This allows to cover
>> all types of identified components and you don't need to miss any.
>> 
>> Kind regards,
>> Johannes
>> 
>> Mit freundlichen Grüßen / Best regards
>> 
>> Johannes Kristan
>> INST-CSS/BSV-OS  
>> 
>> Tel. +49 30 726112-432 
>> 
>> 
>> -----Ursprüngliche Nachricht-----
>> Von: sw360-dev-bounces@xxxxxxxxxxx <sw360-dev-bounces@xxxxxxxxxxx> Im Auftrag von Michael C. Jaeger
>> Gesendet: Freitag, 11. Januar 2019 11:54
>> An: sw360 developer discussions <sw360-dev@xxxxxxxxxxx>
>> Betreff: [sw360-dev] Oldie but goldie: Component Identification
>> 
>> Hi,
>> 
>> I am sitting here with Alex from Codescoop and we are discussing how to match component entries between two systems. eventually we do not see another approach than
>> 
>> * use the artefact management domain as part of the identification for a component
>> * allow for some low percentage missing mappings to get it actually working
>> * because any own ids are not suitable
>> 
>> The next thing is how to actually apply a common naming for things like maven, nuget, pypi, composer, deb etc etc. because also you could have a decision on "mvn" or "maven", or composer vs cmp, and more discussions alike and how to have a compiled list on the first hand.
>> 
>> Of course we remember the purl proposal by Philippe and we are very much fond of taking the purl proposal for a definitive list of "artefact management domain" names which referred there as type:
>> 
>> https://github.com/package-url/purl-spec
>> 
>> -> see "Known purl types"
>> -> see "Other candidate types to define"
>> 
>> Any other thoughts on this?
>> 
>> in SW360 on component level we would need to add the field "type" and rename the existing field "category" (where we put value like "lib", "tool", "application", "database", etc.) to be consistent, but I think it is worth it, because the potential for solving a mapping problem and enabling a lot of use cases is huge.
>> 
>> Kind regards, Michael
>> _______________________________________________
>> sw360-dev mailing list
>> sw360-dev@xxxxxxxxxxx
>> To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/sw360-dev
>> _______________________________________________
>> sw360-dev mailing list
>> sw360-dev@xxxxxxxxxxx
>> To change your delivery options, retrieve your password, or unsubscribe from this list, visit
>> https://www.eclipse.org/mailman/listinfo/sw360-dev
> 
> -- 
> Maximilian Huber * maximilian.huber@xxxxxxxxxxx * +49-174-3410223
> TNG Technology Consulting GmbH, Beta-Str. 13a, 85774 Unterföhring
> Geschäftsführer: Henrik Klagges, Dr. Robert Dahlke, Gerhard Müller
> Sitz: Unterföhring * Amtsgericht München * HRB 135082
> _______________________________________________
> sw360-dev mailing list
> sw360-dev@xxxxxxxxxxx
> To change your delivery options, retrieve your password, or unsubscribe from this list, visit
> https://www.eclipse.org/mailman/listinfo/sw360-dev