Proposal: Add signature_url as qualifier to generic purls

[shibumi]

Many packages provide a signature. We should add a signature_url qualifier to the generic package url.

[stevespringett]

Thanks for the suggestion and PR.

• In some ecosystems, the signature can automatically be derived from an existing purl (e.g. Maven)
• Some ecosystems support multiple signatures (also Maven)

Since log4j is on everyones mind this week, how would signatures of log4j-core v2.17.0 be represented?

[shibumi]

To be honest I was mostly interested in tarballs, because that's what I have to deal with at most. I am an Arch Linux package maintainer and we compile software from source, via downloading the source tarball from Github/Website/etc.

i see that log4j provides signatures as well:

https://repo1.maven.org/maven2/org/apache/logging/log4j/log4j-core/2.17.0/log4j-core-2.17.0-test-sources.jar https://repo1.maven.org/maven2/org/apache/logging/log4j/log4j-core/2.17.0/log4j-core-2.17.0-test-sources.jar.asc

It's a fat jar (I guess), hence I would just use the generic package url for downloading the jar as well.

[pombredanne]

@shibumi I have mixed feeling about overloading things with standard extra qualifiers and URLs and .... I wonder if this could be tried out first for arch only? and see if this works OK at scale?

[shibumi]

@pombredanne I understand your concerns about overloading the purl with just another qualifier. Would you have another, maybe better, solution for providing a signature? Maybe a 'new' purl called generic secure url?

@dlorenc What do you think about this issue here? Do you see another solution for cosign + purls?

[Rush2112hale]

Sorry to me so long I've been in the hospital for three months

[Rush2112hale]

Thanks I've been sick for a while sorry it took so long

[pombredanne]

@shibumi re:

I understand your concerns about overloading the purl with just another qualifier. Would you have another, maybe better, solution for providing a signature? Maybe a 'new' purl called generic secure url?

I am not saying that using a qualifier is not OK, rather that it would make sense to experiment first.

IMHO you should experiment at some scale first how to evaluate how this works for you (say for Arch Linux) with working code and then based on this, report back here?

[shibumi]

IMHO you should experiment at some scale first how to evaluate how this works for you (say for Arch Linux) with working code and then based on this, report back here?

We are months + lot's of community discussions away from testing this on scale for Arch Linux. Arch Linux was just an example. Having signatures on the generic url specification is a good use case for every distribution and tools that download generic tarballs or any other artifact.

EDIT: Actually, we need this for our sigstore sget client: https://github.com/sigstore/sget/issues/50

[SteveLasker]

Is this asking to encode a fixed url/location for a signature?

[shibumi]

@SteveLasker yes, correct. Having a fixed location for a detached signature is common practice in software distribution. The signature is usually computed over the archive of the source code or the checksum file. Just to mention a few projects:

• glibc: https://ftp.gnu.org/gnu/glibc/
• gnupg: https://gnupg.org/ftp/gcrypt/
• gopass: https://github.com/gopasspw/gopass/releases/tag/v1.13.1
• Python: https://www.python.org/ftp/python/3.9.9/
• Golang: https://storage.googleapis.com/golang

I am sure I can find many other big, relevant projects. It's common practice to use detached signatures, hence I don't understand why this need testing to be honest.

[pombredanne]

@shibumi re https://github.com/package-url/purl-spec/pull/145#issuecomment-1040037809

I am sure I can find many other big, relevant projects. It's common practice to use detached signatures, hence I don't understand why this need testing to be honest.

Yes! this is common enough: maven would be an example with million packages with a detached .asc signature. As in https://repo1.maven.org/maven2/org/glassfish/javax.json/1.1.4/ . In his case though the signature is IMHO something that's entirely derivable from the package type and the purl.

The reason why I am taking some time is that each addition to a simple spec is making it a bit less simple, one tiny addition at a time... so it is always best not to rush things IMHO! I hope you can appreciate the motivation.

[SteveLasker]

I'm totally supportive of detached signatures. It's the basis for Notary v2 and detached references for anything with ORAS Artifacts. I was just clarifying the intent, before raising the concern with having the signature URL as a coupling of "identity and location". See #127 for a discussion, and this post: Separating Identity From Location

When a user copies the artifact (package, container, wasm, sbom, scan result) to their private environment, following best practices for consuming public content, is the user expected to reach that signature location from within their private network?

[shibumi]

@pombredanne yes your motivation is clear. No worries :)

@steveLasker normally you would download the artifact and the signature together from a public location and then verify the signature. In your particular case the signature is in the OCI image embedded (this is common practice as far as I know). This PR here, is mainly about generic artifacts (software archives, arbitrary files, etc). For downloading OCI Images I would use a different package URL to be honest.

[SteveLasker]

Thanks @shibumi. Can this be clarified as a hint, as opposed to a definitive location? In the promotion scenario, I'm hoping we help folks enable the artifact and the signature (even if from another location) can be promoted into the destination environment.

This is the permanent location, vs. runtime discussion. Where is the signature now? Oh, there's a hint that's it's at storage.example.io. When I copy the package, and the signature into the private environment, the signature location is different.

The user wants to promote an artifact from a public location to private:

• Before pulling the artifact, verify the signature from storage.example.io
• Validation complete
• Copy the artifact to artifacts.acme-rockets.io
• Copy the signature to storage.acme-rockets.io

Copies from the internal staging location to a production environment that has a different vnet.

• Before pulling the artifact, verify the signature.
• Validation complete
• Copy the artifact to prod-artifacts.acme-rockets.io
• Copy the signature to prod-storage.acme-rockets.io