On 2020-08-18 at 18:43:45, Jimit Bhalavat wrote:
> 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.

Assuming the config file is the standard one and not a custom config
file, this seems fine.

> 	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.

Having multiple signatures is tricky, but I'm willing to reserve
judgement until I see this.  I'm not opposed in principle.

> 		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.

As Junio said, we prefer to look at patches rather than a proposal, but
I so far am happy with what you've proposed.  Assuming your code is of
good quality, I can see this being a viable design and I'd be happy to
see these changes come in.

I expect some conflicts with some future SHA-256 work I'm doing, but
that's my problem, not yours.
-- 
brian m. carlson: Houston, Texas, US