You are not logged in.

#1 2019-05-10 03:46:05

johnraff
nullglob
From: Nagoya, Japan
Registered: 2015-09-09
Posts: 12,557
Website

[DONE] Debian derivatives signing key info request

this message came on the debian-derivatives mailing list:

Hi all,

The derivatives census has long needed to properly verify signatures of
the apt repositories of derivatives in the census. Until now we have
been faking good signatures using somewhat brittle hacks.

To that end, I'd like to hear about derivatives' handling of apt
repository OpenPGP keys. Based on the discussion I'll update the census
template to get more info and try to work on improving the situation.

I'm particularly interested in a few things:

How would new users bootstrap trust of your keys?

How do you handle updates to your keys?

How do you handle replacement of your keys?

How would Debian users securely obtain your keys for use in chdist or
apt-venv? These allow running apt commands on alternative repositories
without adding those repos to your system configuration.

--
bye,
pabs

https://wiki.debian.org/PaulWise

I'd like to send a reply - or you could send one directly yourself if you want. Anyway I think it would be good for BL to show we are concerned about maintaining standards on things like this. What should we say?

Last edited by johnraff (2019-06-22 03:35:49)


...elevator in the Brain Hotel, broken down but just as well...
( a boring Japan blog (currently paused), now on Bluesky, there's also some GitStuff )

Introduction to the Bunsenlabs Boron Desktop

Offline

#2 2019-05-11 12:00:03

nobody
The Great
Registered: 2015-08-10
Posts: 3,655

Re: [DONE] Debian derivatives signing key info request

Hi John,

I wrote some comments; if you feel you need to revise or add to them, please feel free to do so.

> How would new users bootstrap trust of your keys?

  * Installation of our derivate is possible using ISOs or installing packages
    on top of plain Debian.

  * ISO path:
    * ISO contains the current keys
    * ISO is downloaded using HTTPS (valid certificate) or BitTorrent
    * Users are encouraged to check the ISO file against a detached PGP
      signature (same signing key actually)
    * The public key is retrievable using HTTPS
    * Commands for verifying are listed on the install website

  * Package path:
    * Users retrieve the PGP key using HTTPS
    * Users check the fingerprint
    * Users import the key into their APT keyring

> How do you handle updates to your keys?

  * We forked the debian-keyring package as bunsen-keyring. See
    <https://github.com/BunsenLabs/bunsen-keyring>.

  * The package is included in the base ISO. The package is required by our
    catch-all meta package if the user chose to install without our ISO image.

  * Upon installation, the package ensures that the global APT keyring doesn't
    contain our keys. The package deploys our keys to /etc/apt/trusted.gpg.d.

  * Updates to the keys thusly happen through our signed repository.

  * The key is valid for 2 years and gets updated for another period before
    expiration. If the user does not update his system within two years at least
    once, he has to manually download the current keyring package using HTTPS.

> How do you handle replacement of your keys?

In the context of the bunsen-keyring package, replacement and updates are the
same thing (exchaing the key file in /etc/apt/trusted.gpg.d).

> How would Debian users securely obtain your keys for use in chdist or
> apt-venv? These allow running apt commands on alternative repositories
> without adding those repos to your system configuration.

I'm not familiar with these tools. Since we have the following available:

  * Signing key at a HTTPS URL or keyring package at a HTTPS URL
  * Signed, standard APT repository
  * A catch-all meta package

and hard-depend on the standard Debian repositories, any tool that allows
specifying additional repositories, a key by URL and a package to install would
be suitable to deploy BL in a container or chroot (effectively being the
package-based install path from before).

BL was never meant to be bootstrapped without a Debian repo, so we do not offer
single-source repositories and depend on repository composition instead. Various tool make this simple, complicated or impossible.

Offline

#3 2019-05-11 12:28:06

hhh
Gaucho
From: High in the Custerdome
Registered: 2015-09-17
Posts: 16,036
Website

Re: [DONE] Debian derivatives signing key info request

nobody wrote:

In the context of the bunsen-keyring package, replacement and updates are the
same thing (exchaing the key file in /etc/apt/trusted.gpg.d).

Typo, *exchanging the key file. Otherwise it looks excellent.


No, he can't sleep on the floor. What do you think I'm yelling for?!!!

Online

#4 2019-05-21 03:40:04

johnraff
nullglob
From: Nagoya, Japan
Registered: 2015-09-09
Posts: 12,557
Website

Re: [DONE] Debian derivatives signing key info request

I left this a couple of days in case there were any more comments... then forgot about it.  :8

Thanks, apart from @hhh's fix, and derivate > derivative, your answer looks just right, and I'll forward it to the debian-derivatives ML now.


...elevator in the Brain Hotel, broken down but just as well...
( a boring Japan blog (currently paused), now on Bluesky, there's also some GitStuff )

Introduction to the Bunsenlabs Boron Desktop

Offline

#5 2019-05-21 03:56:29

johnraff
nullglob
From: Nagoya, Japan
Registered: 2015-09-09
Posts: 12,557
Website

Re: [DONE] Debian derivatives signing key info request

Oh yes, this reply came on the list - I don't know if Paul Wise's suggestion has any relevance for us?

Paul Wise wrote:
Sébastien Duthil wrote:
Paul Wise wrote:

How do you handle replacement of your keys?

In case of a key being compromised, then I guess a manual intervention
would be required to revoke the compromised key and to replace it. I
would love to read a better answer though.

One option is to pre-generate the next key, include it in your keyring
package then remove the old key if it gets compromised. You can also
do this replacement on a regular basis, such as once per release. I
think this is how Debian's keys work.


...elevator in the Brain Hotel, broken down but just as well...
( a boring Japan blog (currently paused), now on Bluesky, there's also some GitStuff )

Introduction to the Bunsenlabs Boron Desktop

Offline

#6 2019-05-21 06:02:39

nobody
The Great
Registered: 2015-08-10
Posts: 3,655

Re: [DONE] Debian derivatives signing key info request

johnraff wrote:

Oh yes, this reply came on the list - I don't know if Paul Wise's suggestion has any relevance for us?

Paul Wise wrote:
Sébastien Duthil wrote:

In case of a key being compromised, then I guess a manual intervention
would be required to revoke the compromised key and to replace it. I
would love to read a better answer though.

One option is to pre-generate the next key, include it in your keyring
package then remove the old key if it gets compromised. You can also
do this replacement on a regular basis, such as once per release. I
think this is how Debian's keys work.

Well, it would be good practice. The OpenBSD people do key rotation in this manner too (though they don't use GPG, they use their own signify tool). I'll think about this.

Offline

Board footer

Powered by FluxBB