rhkramer@gmail.com writes: > On Wednesday, August 19, 2020 09:33:04 AM Wouter Verhelst wrote: >> If the term "malicious DD" is reasonable, we have a bigger problem than >> "votes twice" or "uploads a backdoor". >> >> aka, "a malicious DD exists" is already a problem. > > Do you have a suggested solution? > > I believe there are circumstances in which a non-malicious DD could evolve to > a malicious DD. > > Or that a malicious DD could be very hard to detect if he didn't want to be > detected (e.g., sociopath / psychopath). Conjuring up a "mallicious DD" seems to carry with it the assumption that only bad people do bad things, which seems naive to me. This conversation reminds me of the trade-offs involved in airport security. One can decide to spend money on security theatre (e.g. expensive scanners) or general resilience (e.g. more ambulances and emergency responders). The former are much easier to point at, but the latter do more to save lives because people having a medical emergency while queing for checkin is _way_ more common than someone with actual terrorist intent deciding to try to sneak an actual weapon through security. In this situation, tightening up our proceedures regarding keys strikes me as much closer to the security theater end of the spectrum, while efforts like Reproducible Builds are at the general resilience end. If I were a sociopath contemplating sabotage in the Free Software sphere, going to the effort of becoming a DD, even for the first time, would be nowhere near the top of my list. Does DAM actually have any cases at all where they suspect a previously expelled DD of trying to sneak back into the project under a new ID? If not, then either our proceedures are already broken enough that temproarily slackening keysigning protocols won't make the slightest difference, or the threat is probably not worth worrying about. Cheers, Phil. -- |)| Philip Hands [+44 (0)20 8530 9560] HANDS.COM Ltd. |-| http://www.hands.com/ http://ftp.uk.debian.org/ |(| Hugo-Klemm-Strasse 34, 21075 Hamburg, GERMANY
Attachment:
signature.asc
Description: PGP signature