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. J. -- Where's your fishing rod, lawn ornament? This .sig brought to you by the letter B and the number 19 Product of the Republic of HuggieTag
signature.asc
Description: PGP signature
