openSUSE talk:ALP/Workgroups/Git-Packaging-Workflow/WorkPackages/Multi-signature review handling idea

Jump to: navigation, search

TODO for implementing tool support

  • It is my understanding (though I might misremember) that upstream git doesn't want to extend the commit-meta-key gpgsig for multiple signatures. Can we agree with upstream on a new key name and semantics or on extending the semantics of the existing one? Other implementations also need to be considered (libgit, Github, etc.). The same should also be done for ssh and possibly for smime. As git-verify ( https://gitlab.com/source-security/git-verify/ which is not yet? part of git) plans to support ssh side by side with gpg signatures. If agreement with upstream can be reached, it can be implemented in git-verify.
  - This is discussed in the reference document for multiple signatures. It was deemed that there is no demand for mutliple signatures. Regarding other types of signatures, let's concentrate on GPG which we already use internally.
  • How do old git versions know to ignore a new keys should be omitted from the data used for signatures? Should a commit-meta-key prefix be reserved for this?
  - I don't think we need to worry about old git versions or tooling in general. The default operation of git is to ignore signatures in the first place ;)
  • What happens when both gpg and ssh signatures are present, do they each still validate on their own? Or any combination of signature relevant commit-meta-keys.