Understand the details of Fedora Infra signing process

[dustymabe]

We've had a few discussions recently about "signing" artifacts and metadata and if what infrastructure we can rely on for this. Fedora has an automated process that uses the robosignatory software to achieve this goal. We'd like to understand the architecture of how robosignatory is set up and the requirements it has. This should help us figure out if there are any new features we need and if this is something that can be done in collaboration with Fedora Infrastructure or not.

This should involve getting together with @puiterwijk and @nirik from fedora infrastructure and asking them to for an overview of the architecture and software.

Note also that CL has "signing server" software too that was recently written I believe: https://github.com/coreos/fero

[dustymabe]

@bgilbert @ajeddeloh - might also be worth presenting on fero architecture during this meeting.

[dustymabe]

We met today to discuss this.. Here are some rough notes:

Signing Server Infrastructure

Fedora Signing Server Infra/Software

• Infra is built around a couple of different parts:
• Currently use a system called sigul (network hsm solution)
  • 1. Server (contains the private keys)
    • No inbound connections, only outbound connection is bridge
  • 2. Bridge
  • 3. Client
    • Clients connect to bridge
    • Client can be anything or any system that has a client side certificate and proper network access
    • Sigul-client software can act as a client
  • Each user who has access to a key has their own passphrase for a particular key
  • On the vault we use a yubikey (hardware)
  • On the client we use a TPM
  • Robosignatory integrates sigul software and operates on fedmsg
    • Fedmsgs are signed and verified so robosignatory can trust them
    • This is how ostree commits are signed today
    • Rpms are signed this way
  • Non-automated signing
    • Release artifacts are signed manually today
    • Here is the atomic host release code that does the signing of the artifacts: https://pagure.io/releng/blob/master/f/scripts/push-two-week-atomic.py#_416
  • Key rotation
    • Fedora generates a new key per release
    • How does rpm-ostree/ostree use key rotation?
      • We just added the ability to specify a directory or a “glob” to define the keys you use for an ostree remote lib/repo: Search a list of paths in gpgkeypath for gpg keys ostreedev/ostree#1773

CL Signing Server Infra/Software

• CL uses a software called fero https://github.com/coreos/fero

• Uses a yubi-hsm

• Needs multiple developer signatures to sign something

• Benjamin: Currently in Fedora and in CL release artifacts are signed manually. Should we go the automated route in the future?

  • Patrick: Prior to robosig the only way would to automate signing would be to store the user key pass on a server, so we didn’t do it for that reason. We added hardware binding which alleviated concerns around that, so we were able to automate it.

[dustymabe]

I believe the outcome of this meeting is that it seems like we should be able to use the existing robosignatory automatic signing mechanism by publishing fedmsgs to request signing occur. Any new issues we find we will create new issues to discuss what's needed for them.