Le dimanche 18 mars 2018 à 19:23:53+0000, Jonathan McDowell a écrit : > On Thu, Mar 15, 2018 at 11:59:25AM +0100, Mattia Rizzolo wrote: > > On Wed, Feb 14, 2018 at 10:06:24PM +0000, Jonathan McDowell wrote: > > > Fingerprint changes are currently allowed for anyone who doesn't have an > > > account in LDAP, which includes DMs without a guest account. However > > > this means that the DM keyring gets out of sync with what nm.debian.org > > > thinks is the state of the world. "hibby" is a good example of this. > > > > I changed hibby back to the key he had before. He clearly wasn't using > > his new one, and his change was fairly old. The most similar case now > > is tkren, see below. > > > > We have 3 other cases right now: > > [snip 2 DM -> DD cases] > > * weinholt: > > DD returning from retirement; he had to add a new 4096R key as his > > past 1024D was no good anymore. We will have just to wait for this, > > but how would you have handled it from the keyring-maint side? I > > don't believe you'd have liked a "emeritus key rollover" :P > > This is an emeritus DD to DD status and is explicitly allowed by the > site - I agree this should be the case. The case I'm interested in > preventing is someone with a key in an active keyring managing to change > the fingerprint nm.d.o thinks is authoritative for them without it > having first been updated in the active keyring. > > > > We shouldn't allow DMs to change their fingerprint via nm.debian.org; > > > once you're part of the project you should go through the usual keyring > > > replacement process. > > > > Enrico told me that the ability to becoming a DD with a key different > > than the one used while being a DM is a feature (i.e., on the > > keyring-maint side it looks like "add new dd key + remove dm key" > > instead of "move key from dm to dd"), and it has been done in the past. > > I don't think it's a useful feature, I think it's just one that happened > to exist as a result of the way things worked before DM was folded into > nm.debian.org. > > > I'm not sure it's a good excuse, and I kind of agree with noodles here; > > however, I also don't think prospective applicants should need to wait > > for the monthly update to start a process if they want or need a new > > key > > The instances I've seen of people changing keys would not have resulted > in processes being held up due to the monthly update. If a key is > compromised the update happens much faster (and should be done via that > method), if it's a case of the applicant moving to a different key but > the old one is still fine then they can continue to use the old key if > they don't want extra delay. And realistically the shortage of AMs is > more likely to cause a delay than the keyring-maint update time. > > I also think there's a slight argument that allowing a backdoor key > change as part of an application process theoretically reduces security. > There is no signed statement of movement from one key to another which > would normally exist, it's just an update in the website.
Done in commit 26d178c7 Cheers -- Pierre-Elliott Bécue GPG: 9AE0 4D98 6400 E3B6 7528 F493 0D44 2664 1949 74E2 It's far easier to fight for one's principles than to live up to them.
signature.asc
Description: PGP signature
