On Mon, Apr 16, 2018 at 7:54 PM, Junio C Hamano <gitster@xxxxxxxxx> wrote: > "brian m. carlson" <sandals@xxxxxxxxxxxxxxxxxxxx> writes: > >> If we just want to add gpgsm support, that's fine, but we should be >> transparent about that fact and try to avoid making an interface which >> is at once too generic and not generic enough. This patch is definitely designed around PGP and CMS, but the config options were intended to leave room for supporting other tools in the future. I think allowing a PEM type to be specified makes a lot of sense for PGP and CMS, but in the future, we can add a `signingtool.<name>.regex` option. Similarly, the GnuPG specific command line options and output parsing can be moved into a helper in the future. My motivation with this series is not just to "add gpgsm support" though. I've been working on some other CMS tooling that will be open source eventually. My goal was to distribute this tool with a wrapper that emulates the GnuPG interface. To me, this series feels like a good stepping stone towards more generalized support for other tooling. > One thing that makes me somewhat worried is that "add gpgsm support" > may mean "don't encourage people to use the same PGP like everybody > else does" and instead promote fragmenting the world. There are a lot of projects for which PGP doesn't make sense. For example, many large organizations and government entities don't operate based on a web of trust, but have established PKI based on centralized trust. For organizations like this, adopting commit/tag signing with CMS would be far easier than adopting PGP signing. There's a chance that 10 different software projects will end up using 10 different signing tools, but I don't see that as a problem if those tools are well suited to the projects. Developers are already responsible for learning how to work with the software projects they contribute to.
