On Fri, Oct 18, 2019 at 12:11:22PM -0400, Santiago Torres Arias wrote: >> It's smaller, but it's not a one-liner. Here's a comparison using >> ED25519 >> keys of the same length: >> >> minisign: >> >> RWQ4kF9UdFgeSt3LqnS3WnrLlx2EnuIFW7euw5JnLUHY/79ipftmj7A2ug7FiR2WmnFNoSacWr7llBuyInVmRL/VRovj1LFtvA0= >> >> pgp: >> >> -----BEGIN PGP SIGNATURE----- >> >> iHUEARYIAB0WIQR2vl2yUnHhSB5njDW2xBzjVmSZbAUCXaniFAAKCRC2xBzjVmSZ >> bHA5AP46sSPFJfL2tbXwswvj0v2DjLAQ9doxl9bfj9iPZu+3qwEAw5qAMbjw9teL >> L7+NbJ0WVniDWTgt+5ruQ2V9vyfYxAc= >> =B/St > >Yeah, the discrepancy mostly comes from pgp embedding a timestamp and a >longer keyid (+a full keyid fingerprint in pgp 2.1+). Minisign keyids >are 8 random bytes, apparently. > >It doesn't seem like an amazing win in terms of succintness, imvho... There isn't, but ED25519 subkeys are still very rare among developers. Many have 4096-bit RSA subkeys, and you can imagine how large the sigs from those are. I want to underline that my use of minisign was specifically for patches sent via email, without the intent of preserving them in git history (which is why in my proposal they are put under the `---` cutoff). Git itself would continue to use PGP signing. (This also means that we don't necessarily need to make this a native part of git -- it can be accomplished by a combination of wrappers, git-format-patch parameters, and a pre-applypatch hook. However, the likelihood of adoption in this case would be very low.) -K