When apt-setup creates a sources.list, it currently just expects every
repository key to be already present in /etc/apt/trusted.gpg or
/etc/apt/trusted.gpg.d/*.gpg.

collecting all keys in one repository means that each key is
authorized to sign other repositories as well.  This lack of scoping
makes it difficult to constrain repository owners from malicious
behavior.  It also makes it difficult to know when to remove old keys
-- should the wheezy archive signing key still be enabled on my buster
system?

In #861695, i'm trying to get debian-archive-keyring to ship the
standard repository keys in /usr/share/keyrings/.  on a system where
that's done, apt-setup should write the sources.list snippets for the
debian repos with a "signed-by" option (see sources.list(5), which
points specifically to the key that should be used to authorize this
repo.

I think doing this right for debian repositories is going to require
#861695 to be corrected first, which is why the first bug report here
("debian sources.list entries should have signed-by options pointing
to specific keys") is marked as blocked by that bug.

But apt-setup can fix its configuration of any pre-seeded local
repositories without waiting on the debian-archive-keyring package,
which is the point of the second bug ("set up local repository keys
using signed-by option, and do not use "apt-key add"").

In particular, generators/60local can place the proposed key into a
file *outside* of /etc/apt/trusted.gpg.d/, and can add the signed-by
argument to the sources.list stanza it creates.

The result of fixing these two bugs should be that new installations
can have an empty /etc/apt/trusted.gpg and nothing in
/etc/apt/trusted.gpg.d/*.gpg, and each repository added will be
individually authenticated.  This is a pre-requisite for being able to
more tightly constrain software repositories (e.g. pinning, etc), and
should be the default of the future.

Thanks for helping to maintain debian-installer!

The idea is to have one GPG file per codename and then let 50mirror
deduce the codename from the Release file and use
/usr/share/keyrings/${codename}.gpg for this? Right now a lot of this
information isn't really available to the scripts because it isn't
needed, after all the chroot that has just been bootstrapped will
contain the trusted keys in a single keyring.

Any idea where these should then actually live? It should be /etc
because it's local configuration, I think. This mechanism loses the key
agility we have with debian-archive-keyring and the reference of a file
updatable by a package instead of a single key but that's maybe fair in
the context of local configuration[*].

Kind regards
Philipp Kern

[*] But nevertheless I guess also inventing some way to transition from
key to key on a repo metadata basis would be nice to have eventually.