Pulp

There is a reason the interface implemented for metadata signing in pulp2 is modifying the file in place.

Sometimes, the plugin writer may not know what types of signatures (detached or not) are needed.

As an extreme (and maybe hypothetical) example, let's look at a yum repository (repomd, really).

yum expects a clear-text signature. zypper expects a detached signature.

At the time the plugin developer writes the plugin, it may not be aware that the repo may even be used for zypper.

So, the plugin should typically only care that a call to make a signature was made. The instance of the signing service, as implemented by the pulp administrator, will decide whether it's a detached or clear-text signature.

Question: What are the use cases for detached versus inline signatures?¶

I'm concerned about the semantic differences when plugin writers expect one type and administrators configuring the signing service could return another. Do we need one, or the other, or both?

Question: Won't the return data returning a public key always return a file ending in .key?¶

I'm asking because the example shows repomd.xml.gpg which didn't seem like a public key specifically by its file extension.

Question: In the case of detached signatures, we're expecting them to the ASCII armor style right?¶

Idea¶

What if we only have the signing service produce ascii armored detached signatures to keep admins from having to configure two types? If we did couldn't we have Pulp's code produce a clearsigned version by combining the detached armored signature to the original signed file and adding the header? Conceptually this made sense to me, and in searching the internet it seems possible https://unix.stackexchange.com/questions/498618/gpg-armor-vs-clearsign/498619#498619

Note this could be a terrible idea.

bmbouter wrote:

Question: What are the use cases for detached versus inline signatures?¶

I'm concerned about the semantic differences when plugin writers expect one type and administrators configuring the signing service could return another. Do we need one, or the other, or both?

I am really not sure what the use case is for inline signatures. Having looked at debian and rpm repositories, I have identified that in all cases an ascii-armored detached gpg signature is provided.

In yum[0] and zypper[1] repos, the repomd.xml file is accompanied by repomd.xml.asc file that contains an ascii-armored detached gpg signature. The zypper repo also provides a repomd.xml.key file with the public key.

In debian repositories[2], the Releases file is accompanied by Releases.gpg file that contains an ascii-armored detached gpg signature.

Question: Won't the return data returning a public key always return a file ending in .key?¶

I'm asking because the example shows repomd.xml.gpg which didn't seem like a public key specifically by its file extension.

The .gpg was a bad example there. Only the plugin writer knows what the files should be named. The sign_file() interface should have a stronger return type that explicitly states what the file represents.

Question: In the case of detached signatures, we're expecting them to the ASCII armor style right?¶

Yes for sure.

Idea¶

What if we only have the signing service produce ascii armored detached signatures to keep admins from having to configure two types? If we did couldn't we have Pulp's code produce a clearsigned version by combining the detached armored signature to the original signed file and adding the header? Conceptually this made sense to me, and in searching the internet it seems possible https://unix.stackexchange.com/questions/498618/gpg-armor-vs-clearsign/498619#498619

Note this could be a terrible idea.

I like this idea. The signing service script would always keep the original file untouched. It would always produce 2 new files: an ascii-armored detached gpg signature and a public key that can be used to verify it. The SigningService.sign_file() interface would always return a dictionary with 3 keys: file, signature, key. The values would be file names in the working directory. The plugin writer would then have to decide what to name these files for their publication.

We could later add a keyword argument called 'inline' and default it to False. When that is set to True, the signing service would attach the signature to the file and return the same dictionary. Except in this case the original file is modified.

[0] http://mirror.linux.duke.edu/pub/centos/8/BaseOS/x86_64/os/repodata/
[1] http://download.opensuse.org/distribution/leap/15.0/repo/oss/repodata/
[2] http://mirror.isoc.org.il/pub/debian/dists/bullseye/

I would try to not make any assumptions about the types of files returned by the signing server, if I can help it.

It's not like pulp users can create instances of a signing service remotely. They need to be set up by a pulp admin, who should be comfortable reading documentation coming from the plugin developer on what the expected output of the signing process should be for that particular plugin, and wrap it in a script of sorts.

Even the assumption that the original file is not to be modified is a stretch. What if some plugin does indeed clear-sign the metadata?

"640kB should be enough for anybody."

I would like to understand more about the drawbacks of the design dkliban proposed in the description. It seems simple enough, extensible, doesn't bake in any assumptions, and the admin configuring the signing service should understand the requirements of the repository type easily enough.

If anything, and I think that's important, I'd add an extensible interface (maybe with environment variables) to specify an optional GPG key fingerprint that pulp_core would know how to extract from the repository metadata, if the repository admin chose to supply one, and maybe the repository name itself. The signing service may use those as it sees fit.

I am sorry I can't seem to distance myself from the current implementation in pulp2 since that's roughly what it does and I find it simple enough, yet extensible.

Since all the use cases so far use an ascii-armored detached gpg signature, it seems better to focus on signing services that produce that. If we discover that some plugin needs to to utilize a different type of signing service, let's make SigningService a typed resource at that time.

If a code change is required to enable other types of signatures / artifact changes, then I doubt it will ever happen.

It feels like a small change to the spec that will buy extensibility in the future.

I'd like for this proposal to address additional information being made available to the signing service. I hinted to it above.

If anything, and I think that's important, I'd add an extensible interface (maybe with environment variables) to specify an optional GPG key fingerprint that pulp_core would know how to extract from the repository metadata, if the repository admin chose to supply one, and maybe the repository name itself. The signing service may use those as it sees fit.

Allowing the signing service script to have more information about what is being signed would allow a single service to handle multiple keys and repositories. We should add this feature. I will open a new issue where we can decide what all we should make available to the signing service script.

Yes, we will need to write additional code to enable additional types of signing. However, the strong typing will make life easier for the user. I can imagine an RPM repository needing two completely different types of signing services: ascii-armored detached signer for the metadata and an RPM signer for individual packages. The user would be better served being able to explicitly select a service that is used to sign the packages vs the service that is used to sign metadata. These services may share some underlying infrastructure, but they perform two completely different things.