Allow persisting apt's keyring and 3rd party repos
a user pointed out that in our documentation about “Configuring additional APT repositories” (https://tails.boum.org/doc/first_steps/additional_software/#index6h1), nothing is said about adding a key to apt’s keyring. so while it is possible to make persistent the addition of an unsigned repository to sources.list, it is not possible to do so with a signed one.
I’d say we should either recommand people to not permanently add whatever custom repo (i.e. not signed with a key already in apt’s keyring), or we should allow and document the persistence of apt’s keyring.
#1 Updated by intrigeri 2020-03-09 09:10:38
> I’d say we should either recommand people to not permanently add whatever custom repo (i.e. not signed with a key already in apt’s keyring), or we should allow and document the persistence of apt’s keyring.
Implementation-wise, I think there are 2 aspects:
Adding a third-party key to the list of trusted key makes that third-party key trusted for any configured APT source, which makes it easier for whoever controls that key to attack the user via an active MitM attack. Feature #10234 would solve this problem.
OTOH, if the user is anyway going to add the corresponding third-party APT source, that third-party APT repo can transparently replace any package that the user has in their Additional Software configuration, even if the user would expect that package to be installed/upgraded from Debian, instead of from that extra third-party repository. So such an adversary does not really need to bother with an active MitM attack if they know what Additional Software config, which in most cases is not a given.
So, I think we should do Feature #10234 before we encourage users to add keys to APT’s trusted keyring.
2. How to document this
The correct way to add new keys to the trusted set is to drop them in
/etc/apt/trusted.gpg.d/, with a “gpg” or “asc” file extension.
So regarding persistence, it would be very similar to how we documented adding APT sources already, i.e. something like:
Until both are done, I believe goupille has a point and if that’s cheap, to avoid user confusion, we should perhaps make it clear that the current doc only works for adding extra Debian repositories.
#2 Updated by sajolida 2020-03-12 00:10:08
- Assignee changed from sajolida to intrigeri
Taking a step back:
- What could be the benefits of adding extra Debian repositories?
- What other Debian repositories can be added like this? non-free? anything else?
- Why don’t we configure non-free in Tails by default? (and get rid of these instructions all the way for now)
#3 Updated by intrigeri 2020-03-14 12:54:06
> * What could be the benefits of adding extra Debian repositories?
Installing non-free software.
> * What other Debian repositories can be added like this? non-free? anything else?
I can’t think of anything else.
> * Why don’t we configure non-free in Tails by default? (and get rid of these instructions all the way for now)
Bug #10130, where we decided to disable non-free, the main arguments were:
- Main goal: avoid users install non-free software without even noticing.
- Positive side-effect: speed up
apt-get updateand other cache operations
- One step towards: allow derivatives to add more repos
#4 Updated by sajolida 2020-03-20 02:00:36
- Tracker changed from Bug to Feature
- Subject changed from any changes to apt's keyring are not persistent to Allow persisting apt's keyring and 3rd party repos
- Status changed from New to Confirmed
- Assignee deleted (
- Type of work changed from End-user documentation to Discuss
- Affected tool set to Additional Software Packages