Install BL apt keys to /usr instead of /etc/apt/trusted.gpg.d?

johnraff · 2021-12-30 02:44:54

Gpg keys in /etc/apt/trusted.gpg.d will be applied to any repositories configured in apt sources lists, with some possible security risks if the BL website were ever hacked and our key compromised. The subject has come up occasionally on the forum, and it might be considered a courtesy to our users to avoid exposing them to even that very slight possibility.

The preferred method of setting a key now seems to be a signed-by option in the apt line, pointing to a file somewhere not in /etc/apt/trusted.gpg.d.

I now have this in /etc/apt/sources.list.d/bunsen.list:

deb [signed-by=/usr/share/bunsen-keyring/BunsenLabs-RELEASE.asc] https://pkg.bunsenlabs.org/debian beryllium main
deb [signed-by=/usr/share/keyrings/bunsen_dev-archive-keyring.asc] https://kelaino.bunsenlabs.org/~johnraff/debian beryllium main

Apt is accepting both those keys and updating, with no key in trusted.gpg.d, so I have concluded that the filepath and filename can both be anything, and that apt will happily accept .asc files as well as .gpg binaries.

There is a Debian Wiki page which outlines suggested standards for configuring third-party repositories:
https://wiki.debian.org/DebianRepository/UseThirdParty
While some of the information there is a bit old (eg I don't think there's any reason to avoid asc files now) we might be best following those guidelines as far as possible, ie:
put keys in /usr/share/keyrings/
and name ours <bunsen OR BunsenLabs>-archive-keyring.asc?

bunsen-keyring currently installs:
/etc/apt/trusted.gpg.d/bunsen-keyring.gpg
/usr/share/bunsen-keyring/BunsenLabs-RELEASE.asc

So we could just drop the gpg file and configure apt to look for the asc file in /usr/share/bunsen-keyring, or alternatively install it to /usr/share/keyrings/BunsenLabs-archive-keyring.asc (or bunsen-archive-keyring.asc)

(The above Wiki page also says that bunsen-keyring should be named bunsen-archive-keyring. That would stop a Lintian warning on the package in fact.)

---
Of course this would mean modifying the instructions we give about configuring apt sources on the forum and website to make sure the signed-by option is included, and making sure live-build does the right thing in our isos. I'm presuming that won't be too hard.

Researching this issue I did come upon an error in our repo setup instructions here:
https://www.bunsenlabs.org/repositories … igning-key
The manual signing key setup commands assume the key is downloaded to /tmp, but it's in ~/

wget https://ddl.bunsenlabs.org/ddl/BunsenLabs-RELEASE.asc
# The following will NOT affect your actual trusted keyring - a transient
# keyring is created in a temporary directory and then deleted. This awkwardness
# is because I cannot figure out how to do this in a portable way across
# different gpg versions and in a way that always works.
tmpdir=$(mktemp -d)
gpg --homedir "$tmpdir" --import /tmp/BunsenLabs-RELEASE.asc &>/dev/null
gpg --homedir "$tmpdir" --fingerprint
rm -r -- "$tmpdir"/

IE the third command should be

gpg --homedir "$tmpdir" --import BunsenLabs-RELEASE.asc &>/dev/null

I haven't researched a variety of gpg versions or linux systems, but FWIW can report that on Debian Bullseye

gpg --show-keys --with-fingerprint BunsenLabs-RELEASE.asc

is enough to see the fingerprint.

nobody · 2021-12-30 16:20:27

It would be alright by me if the key was hosted out of trusted.gpg.d, but it requires to update some docs on www.b.org as well and probably a couple of forum threads as "just restoring sources.list like this" based on old info is no longer going to work then, without transition period. I would suggest to include the definitive sources of every release in bunsen-os-release and a script like bl-restore-repository-configuration which will restore sources.list.d/bunsen.list to the sources.list supported by that release.

johnraff · 2021-12-31 02:32:51

^Thanks for those two good points:

1) It would be good to have a transition period while the new apt line was published via all the channels, before removing the key from trusted.gpg.d. Maybe set up the new sources list entries for Beryllium, and wait till Boron to actually take the key out of the old location?

2) What to do with old releases? Leave the key as it is, or push out some update mechanism? Could a backported update to bunsen-keyring include a postinstall script which incorporated the bl-restore-repository-configuration functionality along with the new key location? I guess editing apt sources - if limited to BL repos - might be just acceptable as something a BL package can do? The alternative of just leaving Hydrogen, Helium and Lithium the way they are might not be out of the question - we could post a how-to for users to do it themselves.

johnraff · 2022-01-09 06:51:55

On further reflection, this all seems like a lot of work for mainly cosmetic purposes. While the main writer of the wiki page posted above seems keen on "signed by", not all Debian devs agree at all.
https://bugs.debian.org/cgi-bin/bugrepo … bug=990086

In practice, security increase is minimal, since package maintainer scripts run as root anyway. But I guess it's better for publicity

https://bugs.debian.org/cgi-bin/bugrepo … bug=980743

We don't yet have sensible ways to do this, really. Dropping files into
/usr is bad practice, and we don't provide a directory to store keys in
/etc. Well maybe they should be in /usr/local/share/keyrings? I don't
know, it's hard to say.
My goal would be to migrate to deb822 sources files with keys embedded
in them eventually, that would solve all issues; but it's blocked by
python-apt's aptsources package and all its consumers which all need to
be changed to be able to understand deb822.

So apt-key is deprecated and will be dropped in Bookworm; for now let's just go on putting keys - and telling users to put keys - in trusted.gpg.d, and wait for proper support of the deb822 format. And if forum users complain we can refer them to the above discussions (or elsewhere in Debland).

#1 2021-12-30 02:44:54

Install BL apt keys to /usr instead of /etc/apt/trusted.gpg.d?

#2 2021-12-30 16:20:27

Re: Install BL apt keys to /usr instead of /etc/apt/trusted.gpg.d?

#3 2021-12-31 02:32:51

Re: Install BL apt keys to /usr instead of /etc/apt/trusted.gpg.d?

#4 2022-01-09 06:51:55

Re: Install BL apt keys to /usr instead of /etc/apt/trusted.gpg.d?

Board footer