feat(dotfiles): automatically sign commits on personal machines

wincent · wincent · commit ec49be762ff3 · 2022-06-19T00:08:22.000+02:00
As described here: https://wincent.com/wiki/GPG_key_rotation_notes I don't even have a signing key my work machine (mostly because I don't want to go through the hoops of getting such a thing working on Codespaces, although it would be easy enough to do it locally on my work laptop). But recent changes in GitHub: https://twitter.com/wincent/status/1535598901486669824 https://github.blog/changelog/2022-05-31-improved-verification-of-historic-git-commit-signatures/ lead me to reconsider my long-help policy of not bothering to sign commits, only tags. If GitHub is going to show signatures even as valid after the corresponding keys have expired, then it seems that it is worth doing after all. Torvalds is well known for saying that signing commits is "stupid": https://news.ycombinator.com/item?id=12290873 https://stackoverflow.com/a/10166916/2103996 > Signing each commit is totally stupid. It just means that you automate > it, and you make the signature worth less. It also doesn't add any > real value, since the way the git DAG-chain of SHA1's work, you only > ever need one signature to make all the commits reachable from that > one be effectively covered by that one. So signing each commit is > simply missing the point. I think this is true in a sense, but the importance of GitHub's UI decisions within the developer ecosystem shifts the balance. Sure, auto-signing _does_ make each signature be "worth less", but at the same time, I am _not_ worried about somebody else impersonating me. Even if my commits are garbage, I am happy to attest to being the one who made that garbage. For me, signing doesn't mean "this is good", but rather, "this is me". GitHub's UI very much reinforces the reading that any given commit was really made by the author. The trade-offs in kernel development are different. For example, as it says here: https://github.com/torvalds/linux/blob/4b35035bcf80ddb47c0112c4fbd84a63a2836a18/Documentation/process/maintainer-pgp-guide.rst#how-to-work-with-signed-commits > It is easy to create signed commits, but it is much more difficult > to use them in Linux kernel development, since it relies on patches > sent to the mailing list, and this workflow does not preserve PGP > commit signatures. Furthermore, when rebasing your repository to > match upstream, even your own PGP commit signatures will end up > discarded. For this reason, most kernel developers don't bother > signing their commits and will ignore signed commits in any external > repositories that they rely upon in their work. Even there, they go on to say: > However, if you have your working git tree publicly available at > some git hosting service (kernel.org, infradead.org, ozlabs.org, > or others), then the recommendation is that you sign all your git > commits even if upstream developers do not directly benefit from this > practice.
diff --git a/aspects/dotfiles/index.ts b/aspects/dotfiles/index.ts
@@ -17,8 +17,9 @@ import stat from 'fig/fs/stat.js';
 
 const {is, when} = helpers;
 
-variables(({hostHandle, identity}) => {
+variables(({hostHandle, identity, profile}) => {
   return {
+    gitGpgSign: identity === 'wincent' && profile === 'personal',
     gitHostSpecificInclude: `.gitconfig.d/${hostHandle}`,
     gitUserEmail: identity === 'wincent' ? 'greg@hurrell.net' : '',
     gitUserName: identity === 'wincent' ? 'Greg Hurrell' : '',
diff --git a/aspects/dotfiles/templates/.gitconfig.erb b/aspects/dotfiles/templates/.gitconfig.erb
@@ -95,6 +95,11 @@
 
 [color "status"]
 	untracked = blue
+<%- if (variables.gitGpgSign) { -%>
+
+[commit]
+	gpgSign = true
+<%- } -%>
 
 [core]
 	attributesfile = ~/.gitattributes
