Add a keyring package

[erikjohnston]

Step 1 of matrix-org/synapse#10389

This just uses dpkg-deb to build the deb, rather than the standard tooling, mainly for simplicity.

This does not update the key expiry time, just packaging up the existing public key.

[DMRobertson]

Seems reasonable. I don't fully understand the machinery, but this seems to do what Rich describes here: matrix-org/synapse#10389 (comment)

When this process is complete, does this mean that anyone who has trusted our current GPG key will automatically trust our future GPG keys without manually verifying them? That sounds scary...

[erikjohnston]

When this process is complete, does this mean that anyone who has trusted our current GPG key will automatically trust our future GPG keys without manually verifying them? That sounds scary...

Only if we update the keyring package with a new key before the existing key has expired. I'd also propose that all new keys still have an expiry, and we just periodically bump the expiry and release a new keyring deb.

It's worth noting that this is not really different than today, if you install our debs then we can do anything and everything to your box (since installation happens as root). So if we go rogue / an attacker gets our private key and access to our package repository, this new keyring package does not open up any new avenues of attack.

[richvdh]

lgtm.

There was a suggestion that we could also check that the old (possibly compromised) key (C35EB17E1EAE708E6603A9B3AD0592FE47F0DF61) isn't languishing in /etc/apt/trusted.gpg or /etc/apt/trusted.gpg.d. But maybe that's a later job.

[erikjohnston]

There was a suggestion that we could also check that the old (possibly compromised) key (C35EB17E1EAE708E6603A9B3AD0592FE47F0DF61) isn't languishing in /etc/apt/trusted.gpg or /etc/apt/trusted.gpg.d. But maybe that's a later job.

Yup, I'd prefer doing that as a separate step if we want it. TBH, I'm not quite sure what the mechanics for doing so are.