> > Do you want to reject signed commits if > - keys are not publicly available [1]
Yes, since that defies the purpose of the signature. > - signatures are from expired keys [2] Yes if the signature was made after expiration. (Dont know if that is even possible.) No if the signature was made while the key was valid. (Otherwise our whole portage tree would time out at some point.) > - keys are revoked [3] Yes. > - keys are not listed in userinfo.xml (current or former devs) [4] Yes. However, for the former devs we might need an extra list to prevent "expiration on retirement", and treat the keys as if they expired on retirement date (compare above). Does that make sense? Of course now we can add additional requirements: * The key must have an userid that refers to an official Gentoo e-mail address. E.g. dilfri...@gentoo.org Very important and easily implemented. * The userid should have some specific "default string" in its comment field, like "Gentoo manifest signing key". Not so important but also easily implemented. * The key should be signed by some central instance for automated validity check. Here things get hairy. How about having recruiter/infra team sign a dev's key on completion of the recruitment process? Just a first thought... * The central instance should be able to reliably revoke a key. Add a revocation list in a portage tree directory? Or is this just shooting yourself into the foot backwards through the eye? Cheers, A -- Andreas K. Huettel Gentoo Linux developer dilfri...@gentoo.org http://www.akhuettel.de/
signature.asc
Description: This is a digitally signed message part.
