Feature Request: support validation of additional git commit signature types

[bb-Ricardo]

Hi,

I'm currently looking into improving the validation of git commit and tag signatures. I already opened a PR to support SSH signature validation here: fluxcd/pkg#1141

I would be happy to implement the support in the source-controller as well but had a few questions regarding the design of the implementation.

In general the GPG validation lacks the configuration options to define a list of valid commiters or authors. This is especially troublesome if an instance key is used to sign the commits (GitLab, GitHub).

To give users the option to use "signed web commits" I would propose following options and implementation:

• GPG and SSH:
  • Verify signatures (GPG and SSH) with provided public keys
  • Verify commit commiter against list of valid commiters, if provided via configuration
  • Verify commit auther against list of valid authers, if provided via configuration
• x509:
  • Verify signature certificate CN against list of valid commiters, if provided via configuration
  • Verify signature certificate agains a CA certificate, if provided
  • support implementations for smimesign and gitsign
  • provide config option to pass further configuration to gitsign (rekor and fulcio configuration)

What are your thoughts on this?

Implementing this would enable our organisation to enforce signed Git commits for Kubernetes deployments. Then the user and organisation can choose which type of git signatures are used which level will be enforced.

[stefanprodan]

The smimesign last release was 5 years ago, I am not considering adding this to Flux. We already struggle with Cosign that imports half the internet and depends on packages unmaintained for years e.g. old Azure SDKs currently archived.

[matheuscscp]

The smimesign last release was 5 years ago, I am not considering adding this to Flux. We already struggle with Cosign that imports half the internet and depends on packages unmaintained for years e.g. old Azure SDKs currently archived.

And the whole point of cosign is improving supply chain 🫠

[bb-Ricardo]

The smimesign last release was 5 years ago, I am not considering adding this to Flux. We already struggle with Cosign that imports half the internet and depends on packages unmaintained for years e.g. old Azure SDKs currently archived.

And the whole point of cosign is improving supply chain 🫠

I know, it is kind of ridicules and contradicting.

But for now I would first care about GPG and SSH signatures.

I would not like to use GPG trust levels and verify them or SSH verified signer format. Mainly to make it easier for the user to specify the list of key and valid commiters and authors. The we could check against the list within the source controller.

Let me know if this sounds feasible or not. Or maybe something I missed. Then I would start with a proposal of a potential yaml example to configure these.

[stefanprodan]

I see no value in the signatures GitHub adds on merge commits via UI. The whole point of GPG/SSH signature verification in Flux, is to reject changes made in Git if some GitHub account was taken over by a bad actor. The assumption here is that the attacker would need to compromise not only your GitHub account but also gain access to your local machine and steal your signing key.

[bb-Ricardo]

I would agree on the public instances, I would not trust them either. But this is more about the use case of self hosted instances. We have multiple GitLab instances in different security zones and I would like to leave this decision to the user.

Different teams have different workflows for their deployments. We for example have Merge Requests where the commits get squashed. And if the security team did an assessment that this GitLab instance is considered secure enough, then these teams could keep their workflow including signed commits.

In gernal this would enable the user/operator to raise the security bar to have signed commits but on an instance level, where the permitted list of users is defined independently.

And if this is not sufficient enough they would just need to remove the instance key.