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 ED25519keys of the same length: minisign: RWQ4kF9UdFgeSt3LqnS3WnrLlx2EnuIFW7euw5JnLUHY/79ipftmj7A2ug7FiR2WmnFNoSacWr7llBuyInVmRL/VRovj1LFtvA0= pgp: -----BEGIN PGP SIGNATURE----- iHUEARYIAB0WIQR2vl2yUnHhSB5njDW2xBzjVmSZbAUCXaniFAAKCRC2xBzjVmSZ bHA5AP46sSPFJfL2tbXwswvj0v2DjLAQ9doxl9bfj9iPZu+3qwEAw5qAMbjw9teL L7+NbJ0WVniDWTgt+5ruQ2V9vyfYxAc= =B/StYeah, 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
Attachment:
signature.asc
Description: PGP signature
