Hello Junio, I am Jimit Bhalavat, and as you know I have been selected by The Linux Foundation to work on the GPG Commit Signing Project. My mentor is David Huseby. I have spent the last few weeks working on a Technical Design Document which specifies how the commit signing works in git and what functions are called. I have done the same for verifying signatures, commit tags, and verifying tags. The aim of this project is that we want to focus entirely on refactoring the signing infrastructure to make it easy for users to support their choice of signing tool while preserving full backwards compatibility with the way things work today. We are NOT at all trying to inject any "emerging technology" into Git, just merely loosening the binding between Git and GPG enough so that users have more choice with signing tools. The detailed technical design proposal is below: What changes did patches make last summer?: The project’s goal was to abstract the current GPG interface into a more ‘generic’ API that supports the existing OpenPGP and X.509 functionality while creating the ability to write additional signature drivers. Currently git supports signing/verifying commits and tags using GPG only. The goal of the project was to make the git signing interface compatible with external signing tools. The main sections of the project were updating the user configuration and the command handling when a signing or verifying operation occurs. The prototype of Ibrahim’s patches has already implemented configuration aliases to ensure that the new approach is backwards compatible with previous configuration. The patches also worked towards improving the documentation for clear transition, along with maintaining backward compatibility. Why were the patches from last summer rejected?: The patches from last summer opted for a config based approach and a tool-agnostic signing interface. The main goal of the project was to abstract the current GPG interface into a more ‘generic’ API that supports the existing OpenPGP and X.509 functionality while creating the ability to write additional signature drivers. The project proposal had already implemented configuration aliases to ensure that the new approach is backwards compatible with previous configuration. The other reasons include: the drivers for external signing tools were still written in C and the patches were not more for a configuration based interface. The patches implement updated user configuration to define signing tools and implement a tool-agnostic signing interface in C code. It also added the possibility to use bash helper scripts to drive additional tools in case the default interface doesn't work as intended. Where are we going next?/What we are trying to achieve?: The main goal of this year’s project is instead of having C code for each new signing tool, we will try define a new standardized pipe forking interface that takes the values from the config file. The config file will contain the following values: which executable to run, what parameters to pass, what regular expressions to use for detecting signature type and pulling the signature out of commits and tags. Part of the patches from last summer update the config format to support any number of different signing tools. If the config file does not have any values using the new signing section format, it defaults to the GPG executable, GPG regular expressions, and the GPG parameters. This ensures that we maintain backward compatibility and preserve existing behaviour for users who have not adopted the new config values. We are going to deprecate things, but old options will not stop working. The proposal: 1. We aim to achieve that instead of having C code that calls all the signing tools, we will try to achieve that only one piece of code will do the standardized pipe forking and take the values from the config file. The config file will contain the following values: which executable to run, what parameters to pass, what regular expressions to use for detecting signature type and pulling the signature out of commits and tags. 2. The current patch uses a set of function pointers, but this project aims to use a struct with the configuration data for the detected signature type such as PGP, x509, minisig, etc. a. When signing, the signature type either comes from the command-line switch or from the signing default as specified in the config file. The config file has different parameters: which executable to run, what parameters to pass, what regular expressions to use for detecting signature type and pulling the signature out of commits and tags. The goal is to try and call the signing tools from one piece of code instead multiple C code. If the config file does not have any values, it defaults to the GPG executable, GPG regular expressions, and the GPG parameters. b. During the verification process, the signature type is detected by using regular expressions from the config file. The regular expression searches for metadata for a matching signature, and the first one that matches, that format is returned and used for the verification. This design also opens up the possibility of having multiple signatures on a commit/tag. c. Once format is determined, a signing_tool struct is initialized for the given format. The struct contains all of the config data for the given tool (e.g. program to run, regex’s, command line switches, etc). 3. The project also aims to improve the signing-interface.c file to work from the signing_tool struct which we created above which contains all of the configuration data for the given tool such as what program to run, regular expressions, and command line switches. The flow of the code should look like this: a. Pass in a signing tool struct to sign commit b. Instead of calling function pointers to the signing-tool-specific “drivers”, it will instead do what the existing code does; however the executable and command line switches all come from the config/defaults instead of being hard coded.. 4. Create a struct for signer_identity: a. This struct will be helpful to load signer_identity from config (e.g. the existing signingkey config item) or command line. b. It stores the signing-tool-specific signer identity string/identifier, so that it can be passed to the signing tool. 5. All of these changes will make sure that we maintain backwards compatibility. We are aiming to deprecate things a little but old options will not stop working. We will preserve existing behavior. The goal is to try and call the signing tools from one piece of code instead multiple C code. Thank you for your time and we appreciate you looking into it. We are open to having conversations and work with you to make a final proposal which we can use to move forward. Thank you once again. Best, Jimit Bhalavat.
