purl for snaps?

[vpetersson]

There currently isn't a way to express Snaps using purl to my knowledge.

Given that the schema looks like this:
scheme:type/namespace/name@version?qualifiers#subpath

If we were to apply this to Snaps, we can use the CUPS snap as an example. As of this writing, it has two channels (edge and stable), each with its own versions. On top of this, we also need to account for architecture.

Borrowing from the Debian example (pkg:deb/debian/[email protected]?arch=i386&distro=jessie), perhaps the snaps should be expressed as follows:

pkg:snap/cups/[email protected]?arch=amd64

The only unknown to me is if Snapcraft should used as a namespace since it is the "official" distribution method.

[alexmurray]

I don't think it makes sense to include the channel as that can be changed at any time by the publisher - instead it should use the revision which is monotonically increasing and identifies a particular individual snap binary package (and it is different for each architecture), whilst the channel can change and the version can be the same for multiple different binaries:

$ snap info cups | yq .channels
latest/stable: 2.4.11-2 2024-10-28 (1067) 71MB -
latest/candidate: ^
latest/beta: ^
latest/edge: 2.4.11-3 2024-11-01 (1070) 69MB -

so really just the following would be enough BUT I think including the snapcraft.io designator might be useful to indicate this came from the global snap store:

pkg:snap/snapcraft.io/cups@1067

[vpetersson]

Yeah I like that style. Are names globally exclusive (ie can you have a clash in a brand store)?

[alexmurray]

No, names are globally exclusive - BUT if someone ever stands up a separate store that is not part of snapcraft.io or one of its brand stores then there could be a name clash - so I think it makes sense to namespace the store

[vpetersson]

Right, so snapcraft.io is the namespace so as long as names are unique in there that's fine. If some spins up foocraft.io, they would use that as a namespace.

I like it.

[matt-phylum]

I like that the revision points to a specific package, but if somebody has installed cups@1067 it's difficult to know whether that is a new or old version of CUPS and what vulnerabilities might be present. It might be good to have qualifiers for the channel and the version, although it seems potentially confusing that the PURL would then have both a PURL version field and a PURL version qualifier with the version field containing the Snap revision and the version qualifier would contain what the user would think of as the version. Maybe it would be better the other way around with a qualifier for the revision.

Right, so snapcraft.io is the namespace so as long as names are unique in there that's fine. If some spins up foocraft.io, they would use that as a namespace.

I think normally this would be handled using a foocraft.io registry_url qualifier.

[alexmurray]

So I was thinking about this a bit more - snaps can exist standalone and in that context they don't really have a revision - the revision is a concept from the store it comes from - and so whilst it may seem redundant (as I previously suggested above) to include arch/version information in addition to the revision, I expect this will actually be needed.

So then the question is whether to use the revision as the 'version' or the version itself - but since in general the version is not unique I still favor using the revision here but then including the version/arch as additional qualifiers, so how about:

pkg:snap/snapcraft.io/cups@1067?version=2.4.11-2&arch=amd64

And then for locally built and installed snaps that do not come from a store - snapd gives them a monotically increasing revision like x1 or x2 etc - in that case perhaps we use x as the revision to indicate it is local - ie.:

pkg:snap/localhost/cups@x?version=2.4.11-2&arch=amd64