Hi, I'm new to this mailing list, having joined hoping to contribute to Debian, so I hope you won't mind me offering my opinion here, with this being a subject I'm quite keen on.
> On 15 Nov 2023, at 12:01, Salvo Tomaselli <tipos...@tiscali.it> wrote: > > In data mercoledì 15 novembre 2023 03:21:34 CET, Simon Richter ha scritto: >> disqualifying factor. Upload permissions are tied to a gpg key, and the >> holder of the key needs to at least demonstrate good practices in using >> gpg > > I was recently discussing with pypi and core python developers, and it seems > that their take is very different than ours. > > [...] > > Perhaps we need an explicit policy in how to handle keys, since there are > very > different opinions about what it is ok to do with them. PGP/GPG signatures used in this way offer an origin-of-data proof and non-repudiation tied to whoever controls the private key – there are no grey areas. If a private key is stored on an end-user's device, that means anyone who has access to said device OR can compromise said device. If a device is backed up, this of course extends to whoever can access or compromise said backup. And if the private key is processed by a service such as Proton Mail, then the origin-of-data proof and non-repudiation properties extend to whoever has access to Proton Mail systems or whoever can compromise it. The value of a digital signature will weaken as this list gets longer. This is, of course, not to say that the Proton Mail people are in any way ill-intentioned or that their service can be easily compromised. My point is that it is the responsibility of whoever accepts a digital signature as an origin-of-data proof to understand its value and the associated risks. The risks are unlikely to be nil, but can be accepted or reduced; they should never be ignored, though. That means you *can* accept the fact that a disgruntled Proton Mail employee or someone who compromises them could generate signatures, you just shouldn't ignore that fact. There are many more related issues here, such as the fact that even though a private key is normally encrypted at rest (which usually covers its confidentiality aspect for backups), encryption should never be considered perfect or valid in perpetuity – limits for how long encryption is considered to offer confidentially are generally established based on algorithm and key length (usually on the order of a few years) and this, in turn, dictates the need to generate new private keys in the PGP/GPG case (since loss of confidentiality of a private key implies loss of the origin-of-data proof and non-repudiation for its signatures). My opinion is that it is an excellent idea to have a policy for handling keys – this is very much an industry-recommended practice. To get an idea, SANS has a bunch of information security templates to get people started and this includes a Digital Signature Acceptance Policy [1]; this may be a bit basic for Debian's needs or targeted at other kinds of organisations, but I've mentioned this just so you can get an idea. I really think this is a great discussion to have, because software supply chains are only now becoming something people begin to talk about (and that's really because they're being increasingly targeted by malicious entities). Thank you for your time reading this! [1] https://www.sans.org/information-security-policy/?page=2 -- Luci Stanescu Information Security Consultant
