apt key handling needs to be properly documented--what to do?
The apt-secure man page in Debian 11 notes that repository signing is
a key part of the Debian security infrastructure. But key parts of it
are not documented. In my opinion that is a significant security
problem, but the apt maintainers clearly do not share that view.
apt-secure's man page says to use apt-key to manage repository keys,
and provides no other information on how to manage them, not even
mentioning /etc/apt/trusted.gpg.d/. The apt-key manpage, on the other
hand, says the program is deprecated and you should not use it. But
it provides no clue about what you should do instead, aside from
referring you to apt-secure (!). Nor does it seem to be documented in
other man pages or /usr/share/doc/apt, or apt-doc.
Bugs have been filed about this going back to 2020:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=968148 and
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=990521. The
maintainers have consistently minimized the problem, first of all by
downgrading the priority of those bugs to minor, and second by
offering a variety of sometimes inconsistent responses:
1. The priority is to get people to stop using apt-key. Apparently
this is not served by offering them any guidance about what they
should do instead, but just by putting in deprecation warnings. So
the failure to document an alternative leads to people sticking with
apt-key, and the fact they stick with apt-key is given as a reason to
"deprioritize" giving them guidance.
2. There are obvious alternatives. The fact that they are obvious
to the maintainers doesn't help the rest of us.
3. The best alternative isn't obvious. This seems a poor reason to
leave people adrift.
As noted in other parts of those bugs, and in other bugs, people
continue to do the "wrong" thing, like trying to use keys in the wrong
format (for that matter, add-apt-repository does that itself, as I
recently discovered,
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1012649) or
selecting wrong, or at least security-questionable, options, when they
try to populate /etc/apt/trusted.gpg.d/.
An additional problem is that stable is frozen, so that the bar for
updates is higher (one of the reasons given for lack of action earlier
was that a release freeze was in effect).
The lack of documentation seems to me to merit both a higher priority
and a faster response. And the security concerns seem to me clear
justification for an update to stable.
Any suggestions about how to do that?
I hasten to add, in anticipation of the inevitable "submit a patch",
that the patch should come from someone who actually understands the
security infrastructure. Which is not me, because it's not
documented.
Ross Boylan
Reply to: