[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Bug#990521: I wonder whether bug #990521 "apt-secure points to apt-key which is deprecated" should get a higher severity



On 7/1/21 10:40 AM, Jeremy Stanley wrote:
Yes, that's a community-maintained wiki article with a few editors
(at least most of whom are also DDs in this case), started in
2017-03-22 to describe a specific model which discourages it, but
nowhere does that claim use of /etc/apt/trusted.gpg.d is officially
deprecated and when, much less link to official documentation
stating so. The article also does essentially nothing to explain the
risks that model wants to counter. Reading between the lines, it may
protect you from accidentally using a package repository (whose
maintainers you implicitly trust) in unintended ways. If the people
in control of those keys wanted to take control of your machine,
they still could, so it's not protecting you from any intentionally
malicious threats.

It might be good to get input on this from anarcat and dkg, as the
primary authors of that document, on the underlying intention, and
maybe add some further explanation to it indicating the real-world
threats this recommendation mitigates. Security policy should be
informed by risk analysis, and complicating things with additional
security controls which bring no appreciable improvement to the
actual security of the system but just "because you can" is
ultimately detrimental.

Hmmm. Perhaps the messaging around this could be cleared up then, to let people know that /etc/apt/trusted.gpg.d is not actually deprecated. A while back we received a bug report about our company's APT repository:

https://gitlab.kitware.com/cmake/cmake/-/issues/22245

The filer pointed us to this article claiming we should not use /etc/apt/trusted.gpg.d:

https://www.linuxuprising.com/2021/01/apt-key-is-deprecated-how-to-add.html

In response, we updated our keyring package to remove the /etc/apt/trusted.gpg.d files that had been added, and automatically replace them with [signed-by=] attributes in the sources.list (with permission from the user.) It sounds like this move was not necessary. Nevertheless, is it considered "wrong" to do it this way? Should I have left it alone?

Kyle


Reply to: