230982 2021-09-29 13:48:27 -0700 [GTK] Sign releases using a modern GPG key and publish it on webkitgtk.org 2021-09-29 13:48:27 -0700 1 1 1 Unclassified WebKit WebKitGTK WebKit Nightly Build PC Linux NEW P2 Normal --- 1 mcatanzaro webkit-unassigned bugs-noreply oldest_to_newest 1798541 0 mcatanzaro 2021-09-29 13:48:27 -0700 Currently WebKitGTK release tarballs are signed using Carlos Garcia's personal GPG key. In the Fedora spec file, I do this: # Created from http://hkps.pool.sks-keyservers.net/pks/lookup?op=get&search=0xF3D322D0EC4582C3 # $ gpg --import 0xF3D322D0EC4582C3.asc # $ gpg --export --export-options export-minimal D7FCF61CF9A2DEAB31D81BD3F3D322D0EC4582C3 > gpgkey-D7FCF61CF9A2DEAB31D81BD3F3D322D0EC4582C3.gpg Source2: gpg-key-D7FCF61CF9A2DEAB31D81BD3F3D322D0EC4582C3.gpg This would catch a supply chain attack where (a) distro has previously imported Carlos's key, then (b) attacker compromises webkitgtk.org and replaces tarballs, but (c) attacker does not have access to Carlos's GPG private key. Sadly, hkps.pool.sks-keyservers.net doesn't seem to exist anymore, and sks-keyservers.net is using an unacceptable TLS certificate, so my comment on how to create the .gpg keyring is obsolete. That could be fixed by publishing a keyring on webkitgtk.org, so I could link to that rather than these instructions for how to manually create the keyring. But the keyring should really use a new key, rather than Carlos's existing key, because the existing key is a DSA 1024 key that is weak compared to modern standards. There are probably other best practices to follow (project keys instead of individual developer keys?), but I don't pretend to understand them. GPG is too hard for me....