gpg_verify 1.0 feedback

[Christopher Chavez]

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