The gpg_verify 1.0 PortGroup was added one year ago. I count 5 ports which are
using it (4 of which were setup by the author of the PortGroup soon after it
was introduced). However there are many more ports which could be using it. It
would be nice if one day the MacPorts guide encouraged using this PortGroup.
But I think there are some issues with this PortGroup's design that hinder its
proliferation. Would it be worth improving?
I tried adding gpg_verify to gnupg2 recently. I eventually got it working, but
I wasn't happy enough with the result to be convinced I should submit the
result in a PR, especially since someone else maintained the port. I found
gpg_verify much more tedious to add than compared to other PortGroups. I think
the main reason is that it exposes what I consider "implementation details" the
PortGroup should instead handle itself. One example is creating the separate
post-checksum phase; I'm not aware when else a port would want to do PGP
verification, so this is something that I think could be done in the PortGroup.
Another is passing the complete distfile name to
gpg_verify.verify_gpg_signature, when passing it without prepending
${distpath}/ should be sufficient (I think `global distpath` would work, as
done in the cargo_fetch 1.0 PortGroup). I also wonder if fetching the signature
file could be handled by the PortGroup rather than requiring the portfile to
add it to its distfiles and checksums.
Some other minor issues: The PGP verification step should print some
acknowledgement when it is run with `port -v` and `port -d`; currently it only
prints when there's an error (and without a precise reason specified). And
rather than using a temporary .gnupg directory for each port, maybe a single
permanent .gnupg directory somewhere in ${prefix}/var/macports should be used,
so that keys don't have to be imported from scratch for each port build. I
would also prefer the phrasing "PGP verification" rather than "GPG
verification": PGP is the desired protocol, whereas GPG is just a common
implementation of it (and it shouldn't matter whether it's the one used).
I really do think the PortGroup would be easier to use if all ports had to do
is put the fingerprint(s) in the Portfile, rather than put the entire pubkey in
the ports tree for each Portfile which might use it. If this means having to
fetch the pubkeys, the issue with doing so (as the PortGroup mentions) is the
intermittency of existing keyservers. I suggested using the high-availability
keyserver keys.openpgp.org, but that was deemed too new for MacPorts to rely
on. One year later, it is still around, is somewhat widely used—e.g. as the
default keyserver in PGP suites—and claims 99.9998% uptime so far:
freenode #hagrid 2020-08-23 10:21 UTC <Valodim[m]> since recording uptime with
uptimerobot on 2019-07-09, we had one downtime of roughly one minute, which was
2019-11-11 23:24
I believe it would be good enough for MacPorts' purposes of retrieving a key
for a given fingerprint. The problem with using it now is that GnuPG refuses to
allow importing keys without owner information, which keys.openpgp.org requires
key owners' permission to distribute: https://dev.gnupg.org/T4393. I have tried
several keys for open source projects, none of which whose owner's info is
distributed by keys.openpgp.org. MacPorts might be stuck with storing pubkeys,
but maybe there is a better way of doing so.
I imagine there could be a much simpler interface for this using this
PortGroup, making it more appealing to add it to ports. One possible idea:
gpg_verify.use_gpg_verification yes
gpg_verify.fingerprint hex_fingerprint_1 [hex_fingerprint2 …]
gpg_verify.signature_ext (sig|asc)
The PortGroup would handle fetching the .sig or .asc file for the distfile(s),
and import the key using the fingerprint (if not already imported).
(Maybe the first line is redundant—using the PortGroup or its options at all
would be what enables PGP verification.)
If custom signature filenames or URLs are frequently needed, then there might
instead be options like `gpg_verify.signature_name sigfile` (fetching
${master_sites}sigfile), or `gpg_verify.signature_url url` (fetching a complete
URL to a signature file).
Maybe other package managers have ideas on how to handle PGP verification of
upstream distfiles.
Christopher A. Chavez
