On 2021-07-01 21:46:19 +0200 (+0200), David Kalnischkies wrote: > (Disclaimer: It was me who implemented Signed-By, also most of the > current monster apt-key is, trusted.gpg.d, … I might be a *tiny bit* > biased than it comes to apt and these topics as a result.)
Thanks for that! I do think it's a useful feature, but my knee jerks whenever people blindly follow "security advice" to complicate their lives or the lives of users without applying common sense about what risks are actually being mitigated to warrant that additional burden. > On Thu, Jul 01, 2021 at 02:40:31PM +0000, Jeremy Stanley wrote: > > maybe add some further explanation to it indicating the real-world > > threats this recommendation mitigates. Security policy should be > > Lets not throw the baby out with the bathwater, shall we? [...snip bits about the abject horrors of apt-key...] This was in response to the linked wiki article you helped edit, purporting to represent a "best practice" (ye gods how I despise that term, but let's not go there today) insisting with an RFC 2119 "MUST" that the key not be placed in /etc/apt/trusted.gpg.d, and that seems a bit extreme. I get that you were not the author of the article, but rather merely consulted on it. Still, it seems to have resulted in people unnecessarily demonizing /etc/apt/trusted.gpg.d as inherently insecure. > Many users add countless repos over time, but hardly ever remove > them. They eventually fail or are commented out, but the keys once > added usual stay there until the end of times. So e.g. old RSA1024 > keys for repos you no longer have enabled participate in > verification – sad if said key was compromised in the mean time > and is now used to MITM a repo you still have enabled like Debian > security. [...] I do wholeheartedly agree that there is convenience in being able to effectively drop the trust of a given key automatically by the removal of the source entry/entries tied to it. The aging key scenario is a relatively strong example to support this, albeit mitigated independently by good administrative hygiene. I don't think it rises to the level of a MUST in a "best practice" but I suppose reasonable minds can disagree on this point. > … short: Its fine to drop files into trusted.gpg.d, but you earn > brownie points with me for not doing it and using signed-by as > that is a tiny bit more secure. I did implement it mostly in > preparation for other changes, not because I believed everyone has > to instantly switch to it. [...] So back to my original point in response to the first post in this thread, trusted.gpg.d is not "deprecated" in any real sense, and certainly not officially by the software implementing support for it. > "I shall commit myself to achieve the goal, before this second decade > is out, of landing a patch series to shoot apt-key safely to the moon, > never to return to the main branch again, […] because that challenge > is one that we are willing to accept, one we are unwilling to postpone, > and one we intend to win". [...] Thanks, I'm looking forward to that! -- Jeremy Stanley
signature.asc
Description: PGP signature
