Signing Service Discussion
===

###### tags: `signing service` `meeting`

:::info
- **Location:** #pulp-meeting on IRC
- **Date:** June 10, 2020 11:00 AM (EDT)
- **Agenda**
1. Formally adding one public key to a SigningService?
3. Adding checksum of SigningService script to SigningService?
- **Participants:**
- bmbouter
- quba42
- x9c4
- daviddavis
- **Contact:** Brian Bouterse <[e-mail]>
- **Host:** Brian Bouterse
- **Youtube video**: https://www.youtube.com/watch?v=uecwUFJTWno&feature=youtu.be&ab_channel=Pulp

:::

## Formally adding one public key to a SigningService?

#### Background

See the pulp-dev discussion: https://www.redhat.com/archives/pulp-dev/2020-May/msg00019.html

#### Proposal

current SigningService model: https://github.com/pulp/pulpcore/blob/b94abd64d76ea4554e6750ff38ce458eaa888cc8/pulpcore/app/models/content.py#L380

Add public key to the SigningService object

Question: What about a list of public keys?
We can instead of having a list use N SigningService objects. This avoids the ambiguity of the case where the second signature is signing the first also or just the original plaintext.

Question: Should we make the keys immutable?
Yes, because content signers should be able to leave their existing publications pointing to the old SigningService, otherwise their data will become invalidated.
Yes, because content signers should have to take explicit action when a public key is rotated, especially so they can know to also update clients.

## How to ship a "packaged script" that is reusable

#### Problem

Currently the "key id" is expected to be hard coded in the script which stops a "generic script" from being shipped to Administrators.

#### Proposal

Add non-optional CharField named `key_id` to the SigningService (the base model).
In a subclass the save method will derive that id from the key in the public_key field.
This key_id will be passed to the script.

Then we can ship the script generically as a setuptools asset. A user could also provide their own scripts, it's not necessary to use this one.

## Adding checksum of SigningService script to SigningService?

#### Background

PR to notify user with warning if the checksum changes https://www.redhat.com/archives/pulp-dev/2020-May/msg00019.html

#### Concerns

1. The same script won't be in all the right places

2. When users don't have shared storage putting the script on all workers is practically difficult

3. A shipped script will change

4. A non-shipped script could also change

5. If we place it as an Artifact, it might be too accessible

#### Proposal

Add checksum to the SigningService object
One option that differs from the current PR (https://github.com/pulp/pulpcore/pull/659) would be to trigger an automatic revalidation of the signing service script if the checksum has changed (instead of throwing a Warning).
That way you would at least get a hard error if the changed script does not pass validation.

#### Proposal 2

Add the script as an artifact

## How to create and update Signing Services (on the user/sys admin side)?

#### Background

https://docs.pulpproject.org/en/master/nightly/workflows/signed-metadata.html

#### Questions to clarify

* Should it be (or is it?) possible to create/update SigningServices via the API?
* Does their need to be a clear workflow for updating an existing SigningService?

## Next Stpes

1. Add a public_key to the SigningService. This key is immutable.

---

# Meeting: Dec 14th
* Should pulp verify signature at sync/upload time?
* Should pulp be able to import and retain existing signatures?
* Should pulp re-sign every content unit?
* Can we add signatures, while retaining existing ones?
* Is there a file format for signed collections?
* Detached / attached signatures
* Signature of metadata inside the tarball
* Do we need to be backwards compatible with older ansible-galaxy cli?
* We are talking GnuPG.