nick black
2025-01-11 20:20:01 UTC
i'm beginning to see use of minisign[0] as an alternative to GPG
for signing releases[2]. i'm completely ambivalent with regards to
the merits of minisign, but would like to be able to verify them
with uscan.
looking at the uscan man page and code[1], i don't see any way
to specify an alternative to gpg, though uscan apparently looks
for gpgv, sopv, rsop and friends, and there's already a
tool-specific case in verify() (sopv and gpgv appear to be
cli-incompatible). so adding code to invoke minisign looks
pretty trivial. the problem would be: how do i tell uscan to use
minisign, in the likely presence of gpgv? minisign probably
cannot verify everything gpg can, so we want to continue using
gpg by default.
i could probably convert the minisig signature to a gpg one (not
certain of that), but we'd need some way to tell uscan to do
that, at which point we probably ought just use minisig.
selecting a different verification backend seems orthogonal to
the pgpmode= options of uscan, so it doesn't belong in that set.
adding support would likely mean adding minisign as at least a
Recommends for devscripts, and possibly a Depends. minisign is
pretty small at 16.7 kB downloaded and 49.2 kB installed, but
it does depend on libsodium23, which is depended on by a fair
number of things (including vim for some reason). libsodium23 adds
165/438 kB for a total of 181.7 kB down and 487.2 installed. it
is furthermore crypto-related and thus sensitive; i thought it
prudent to ask the list.
so, unless i'm missing something (totally possible), i'd like to:
1) add a `sigtype` option to uscan, defaulting to 'pgp', with
alternative 'minisign'. other values are errors with exit.
2) explicit provision of `sigtype` in conjunction with either
explicit or implicit `pgpmode=none` (i.e. due to mode=svn)
will be considered an error and result in exit. change
`pgpsigurimangle` to work this way as well (it is currently
allowed in conjunction with pgpmode=none, which i dislike).
3) augment the binary-finding code in uscan to look exclusively
for `minisign` when `sigtype=minisign` (and not look for it
otherwise). failure to find it is error + exit.
4) augment the verification code in uscan to use `minisign`
iff `pgpmode=minisign` and it was discovered in step 3.
5) add `minisign` as a Depends for `devscripts`.
i don't think this justifies any kind of generalized
verification system in uscan (and am not particularly interested
in writing one), nor do i think it's worthwhile to alias or
rename e.g. `pgpsigurlmangle` or `pgpmode`.
i've checked, and a properly ASCII-armored minisign public key
will satisfy uscan up through the verification attempt.
are there objections? am i missing something? thanks! i think i
could have this done todayish.
--rigorously, nick
[0] https://jedisct1.github.io/minisign/
[1] lib/Devscripts/Uscan/Keyring.pm (devscripts-2.24.10)
[2] https://ziglang.org/download/
for signing releases[2]. i'm completely ambivalent with regards to
the merits of minisign, but would like to be able to verify them
with uscan.
looking at the uscan man page and code[1], i don't see any way
to specify an alternative to gpg, though uscan apparently looks
for gpgv, sopv, rsop and friends, and there's already a
tool-specific case in verify() (sopv and gpgv appear to be
cli-incompatible). so adding code to invoke minisign looks
pretty trivial. the problem would be: how do i tell uscan to use
minisign, in the likely presence of gpgv? minisign probably
cannot verify everything gpg can, so we want to continue using
gpg by default.
i could probably convert the minisig signature to a gpg one (not
certain of that), but we'd need some way to tell uscan to do
that, at which point we probably ought just use minisig.
selecting a different verification backend seems orthogonal to
the pgpmode= options of uscan, so it doesn't belong in that set.
adding support would likely mean adding minisign as at least a
Recommends for devscripts, and possibly a Depends. minisign is
pretty small at 16.7 kB downloaded and 49.2 kB installed, but
it does depend on libsodium23, which is depended on by a fair
number of things (including vim for some reason). libsodium23 adds
165/438 kB for a total of 181.7 kB down and 487.2 installed. it
is furthermore crypto-related and thus sensitive; i thought it
prudent to ask the list.
so, unless i'm missing something (totally possible), i'd like to:
1) add a `sigtype` option to uscan, defaulting to 'pgp', with
alternative 'minisign'. other values are errors with exit.
2) explicit provision of `sigtype` in conjunction with either
explicit or implicit `pgpmode=none` (i.e. due to mode=svn)
will be considered an error and result in exit. change
`pgpsigurimangle` to work this way as well (it is currently
allowed in conjunction with pgpmode=none, which i dislike).
3) augment the binary-finding code in uscan to look exclusively
for `minisign` when `sigtype=minisign` (and not look for it
otherwise). failure to find it is error + exit.
4) augment the verification code in uscan to use `minisign`
iff `pgpmode=minisign` and it was discovered in step 3.
5) add `minisign` as a Depends for `devscripts`.
i don't think this justifies any kind of generalized
verification system in uscan (and am not particularly interested
in writing one), nor do i think it's worthwhile to alias or
rename e.g. `pgpsigurlmangle` or `pgpmode`.
i've checked, and a properly ASCII-armored minisign public key
will satisfy uscan up through the verification attempt.
are there objections? am i missing something? thanks! i think i
could have this done todayish.
--rigorously, nick
[0] https://jedisct1.github.io/minisign/
[1] lib/Devscripts/Uscan/Keyring.pm (devscripts-2.24.10)
[2] https://ziglang.org/download/
--
nick black -=- https://nick-black.com
to make an apple pie from scratch,
you need first invent a universe.
nick black -=- https://nick-black.com
to make an apple pie from scratch,
you need first invent a universe.