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
