Rotate / create new repository signing key

[mika]

As noted by cb on IRC (thx!):

% curl -s https://deb.grml.org/repo-key.gpg |gpg --armor --export |wc -l
769520

Our key is very long as plain text, something newer might be shorter.
Also would be nice to use our repository signing key as-is in /etc/apt/keyrings/ via grml.sources.

Last but not least, our latest signing key change dates back to 2015, and we might consider creating a more modern/fresh one also for security reasons.

FTR:

 % gpg keyrings/grml-archive-keyring.gpg 
gpg: WARNING: no command supplied.  Trying to guess what you mean ...
pub   dsa1024/F61E2E7CECDEA787 2006-11-19 [SC]
      709BCE51568573EBC160E590F61E2E7CECDEA787
uid                           GRML Archive Automatic Signing Key (http://www.grml.org/) <[email protected]>
sub   elg2048/896CF7B9B1F9C73E 2006-11-19 [E]
pub   rsa4096/21E0CA38EA2EA4AB 2015-08-16 [SC]
      05483D2F0A254E5BC12AC73021E0CA38EA2EA4AB
uid                           Grml Archive Automatic Signing Key (http://www.grml.org/) <[email protected]>
sub   rsa4096/DC71A66D2B91DE1F 2015-08-16 [E]

I'd be more than happy for any suggestions regarding best practices in terms of GPG implementation usage, key generation settings and command line options. @anarcat maybe might have valuable input for us here? :)

[crpb]

For clarification where it would be beneficial
/etc/apt/sources.list.d/grml.sources

Types: deb deb-src
URIs: http://deb.grml.org
Suites: grml-stable grml-testing
Components: main
Enabled: yes
Signed-By: /etc/apt/keyrings/deb.grml.org.gpg

Here you could replace the Signed-By: filepath with the output of the following commannd (which is currenly a bit of a mess).

wget -qO- https://deb.grml.org/repo-key.asc | gpg --armor --export | sed 's/^$/./;s/^/ /g;1 i Signed-By:' |tee -a /etc/apt/sources.list.d/grml.sources

That way you don't even have to put a file in e.g. /etc/apt/keyrings/.

[zeha]

Do we expect people to have the archive keyring package installed? If not, how will people get the new key?

[crpb]

There needs to be an grml-common which all other packages depend on and so it will be pulled it automatically and then you could add a script like myon's script in postgresql-common. But that needs to be on the debian side.. enough time for trixie? :P

/me duckt sich schonmal

[anarcat]

Hi,

I would suggest considering ECC keys. They are still considered experimental (--expert) in GnuPG, but GnuPG has kind of taken a ride on fork-land recently (Werner forked the OpenPGP process with LibrePGP, taking it back about 10 years) so it's not longer a good reference implementation in my mind.

In this guide I wrote, there's instructions on how to create Curve 25519 keys with GnuPG.

There is certainly a way to do so in Sequoia as well, but it seems that Sequoia only really hit its stride after bookworm was released (with the Chameleon GnuPG compatibility layer, notably), so I didn't use that for those instructions in the aforementioned guide. Reading a bit on the sq manpage, it seems the magic command is sq-key-generate which defaults (imagine that) to cv25519 (!). The downside of this is that (like GnuPG), sequoia stores the generated key in a keyring, which duplicates the secret.

A more canonical way to generate a keys nowadays is probably with the SOP (Stateless OpenPGP) interface, for which there are a couple of implementations in debian as well. Here's the sequoia implementation but there's also a similar rpgpie and gosop implementation, all of which should generally be equivalent:

sqop generate-key 'GRML Archive Automatic Signing Key (http://www.grml.org/) <[email protected]>' > grml-private.key
sqop extract-cert grml-private.key > grml-public.key

Simple, no? :) (While I'm here, I would advise dropping the master, and FTP, but that's a bit out of scope of the advice requested here, I think :p... In fact, I wonder if you even need an email address in there...)

Note that last time I tried to convert an APT repo to ECC, however, it failed: old buster (and bullseye?) servers failed to parse those newer keys. But that's probably not a problem GRML will have other than for really old images.

I think it's a great idea to inject the public key directly in the .sources file, although I don't have personal experience with this. That also limits compatibility with older Debian releases.

re:

Do we expect people to have the archive keyring package installed? If not, how will people get the new key?

Well, if there's an archive keyring, that surely seems like a good way to get this installed. Otherwise, if I remember correctly there's now ways of propagating messages from the repository to the APT client (see the non-free-firmware change, for example), perhaps that could be leveraged to warn people during a transition period?

Otherwise people will just fail to get updates, then look for the key. Just make sure you update it consistently everywhere, and, perhaps, document where "everywhere" is in this process so you make a list for next time (and fix it as you find new moles to whack).

Alright, that's all i got, happy to answer any further questions with my modest knowledge of this.

[zeha]

Well, if there's an archive keyring, that surely seems like a good way to get this installed. Otherwise, if I remember correctly there's now ways of propagating messages from the repository to the APT client (see the non-free-firmware change, for example), perhaps that could be leveraged to warn people during a transition period?

I recall this was hardcoded in apt :(

[guillemj]

I'd recommend storing the archive keyring under /usr/share/keyrings/ with a name like grml-archive-keyring.pgp. Notice the .pgp extension instead of the vendor specific .gpg, given that I think you have never provided a keyring before there's no backwards compat to take care of here, so that would remove legacy to have to take care of in the future.

I'd also echo about trying to put some distance with GnuPG (given their incompatible fork of the ecosystem) and go for either SOP (for completeness there's also the Java-based pgpainless-cli implementation), or sq (although the CLI API has not yet stabilized, but it should be by next January or so I think).

For the question on how to bootstrap the archive certificates, I think there are several options. One could be to upload the keyring package to Debian, there is precedent here, although it might get rejected if it is deemed too niche (perhaps?), another could be to add an entry to https://salsa.debian.org/extrepo-team/extrepo-data, then I guess there's the manual ways via the OpenPGP WOT or a page describing an https URL and certificate fingerprint to bootstrap from (which seems rather cumbersome), and finally I guess there's the YOLO curl+bash method (which ahem :) ).

[mika]

Not sure where we want to actually track this, but to not forget about it and since we need to look into the repository signing key topic anyways together:

I'd also like to get towards a release signing process that does not depend on myself, but instead all our core devs should be able to sign our releases files (ISO/sources/...) and have that working with the instructions at Verify your download.

[guillemj]

BTW, with the just released sq 1.0 (with now a stable CLI!), there's the rather helpful download command (https://sequoia-pgp.gitlab.io/sequoia-sq/man/sq-download.1.html) that fetches and verifies signatures, which might make the instructions perhaps easier to handle. :)