Re: apt key handling needs to be properly documented--what to do?
Yes: that's right on point. I do have some things I'd still like to see. Maybe we should continue on #1002820 to avoid clutter? But that's closed, and so maybe not a great choice. Wishlist: 1. update stable so the information is more widely available. 2. Since apt-key is going away and already deprecated, the info needs to (also?) be available elsewhere. Maybe the man page for apt or apt-secure. 3. The fact that not all .gpg files work should be explicitly documented: keybox files don't work. That is discussed earlier in the man page, but literally it is described as a limitation on apt-key rather than a limitation on the files in trusted.gpg.d (or other locations). 4. It's a bit confusing to describe using /etc/apt/trusted.gpg.d and then say /etc/apt/keyrings is recommended. I guess the former is intended for package authors and the latter for users/sysadmins. 5. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=990521#27 expresses some reservations about the use of signed-by. I don't completely understand them. Finally, though quite possibly out of scope, there's the question of how you get the keys. add-apt-repository, which is not part of this package, goes through a fairly involved series of steps including use of web interfaces and format changes with gpg in order to get a key that's ready to put in trusted.gpg.d (although it then tries to insert the key with the wrong format!). Ross On Sat, Jun 11, 2022 at 10:36 PM Johannes Schauer Marin Rodrigues wrote: > > Quoting Ross Boylan (2022-06-11 09:07:14) > > 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. > > Maybe you were looking for documentation like this: > > https://salsa.debian.org/apt-team/apt/-/commit/4a012436ce6a07dd435dca33b7ee2c41ea94c844 > > Is anything missing from that addition to the documentation that you'd like to > add? Here is a version of the apt-key man page with better formatting: > > https://manpages.debian.org/unstable/apt/apt-key.8.en.html#DEPRECATION > > Thanks! > > cheers, josch
Re: apt key handling needs to be properly documented--what to do?
Quoting Ross Boylan (2022-06-11 09:07:14) > 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. Maybe you were looking for documentation like this: https://salsa.debian.org/apt-team/apt/-/commit/4a012436ce6a07dd435dca33b7ee2c41ea94c844 Is anything missing from that addition to the documentation that you'd like to add? Here is a version of the apt-key man page with better formatting: https://manpages.debian.org/unstable/apt/apt-key.8.en.html#DEPRECATION Thanks! cheers, josch signature.asc Description: signature
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
