Add support for x509 signatures on commits

[jalseth]

Hello,

Currently Flux supports verification of PGP signatures on commits to ensure they come from authorized parties. Git also supports signatures from keys with x509 certificates which has many advantages over PGP for organizations. One example is to have the certificates have short lifetimes (often 1 day or less) so they expire regularly; then, when an individual leaves an organization, their ability to be a trusted committer is automatically revoked once their certificate expires. Similarly, this allows individuals to become trusted committers automatically when they join a team since their certificate will be issued by a certificate authority that Flux is already configured to trust without needing to update the configuration.

Proposal

• Add a SignatureType field to the GitRepositoryVerification struct with options of pgp or x509.
• The source controller checks this field, and if it is not set or is set to pgp it performs the same verifications it does now.
• If the field is x509, the controller reads two keys from the secret: roots and intermediates. These keys are arrays of strings containing the respective PEM encoded x509 root and intermediate certificate authority certificates. These are then passed to the x509 verification function in go-git to validate the commit signatures.
• Bump the GitRepository CRD to v1beta2 since there are new fields, but the default behavior is unchanged.

Dependencies / Blockers

• go-git currently only supports PGP signatures. I'm working on a PR which will add support for S/MIME signature verification to the library to support signatures made with https://github.com/github/smimesign.

[phillebaba]

@stealthybox this feels very similar to the discussions we had last week, this might be up your alley.

There might be an obvious answer but my question is how developers are meant to store and renew their certificates while working. Is there a good process for this?

As we are using two git implementations it might be good to look into if libgit2 supports x509 signatures also.

[jalseth]

Provisioning of the signing keys and certificates is up to each organization and will vary greatly between organizations. Orgs that use Active Directory will probably use Active Directory Certificate Services, orgs using HashiCorp Vault will probably use that, etc. That topic is outside the scope of Flux's concern, same as how Flux isn't concerned with how users manage their PGP keys. That said, I'm happy to discuss on Slack or similar what I think the best practices are.

Regarding git2go, it also does not support x509 signatures at this time. Since git2go is a wrapper for libgit2 I suspect the underlying library does not support it either. Given this, I would prefer that at least for the initial implementation the controller errors if x509 selected with the libgit2 backend. This way the feature can be added, and if there's demand for it to be added to the libgit2 backend as well that can be added at a later date.

[squaremo]

As we are using two git implementations

Checking the signature can be done with whichever library can do it, if the files are on disk.