On 2018-08-04 14:34, Ulrich Mueller wrote: > So this should either have been submitted as part of that update, or > you should at least have given notice to the council that further > changes are pending (as you were present during the meeting). In the > latter case, we may likely have postponed the decision about the GLEP > update, which wasn't entirely uncontroversial.
I agree but nevertheless I appreciate that someone (Michał in this case) doesn't rest and continue to improve things. Michał Górny wrote: > +Furthermore, the specification requires separate subkeys for different > +purposes. This is a generally agreed on practice (e.g. GnuPG defaults to > +using a separate encryption key) aiming to further reduce the attack surface. > +Kristian Fiskerstrand points out e.g. it is technically possible to obtain > +a valid signature over crafted data while using the subkey for purposes > +of authorization [#COUNCIL-MEETING-20180729]_. I challenge this one: If an attacker is already able to trick a developer into signing something the developer didn't want to sign, the same attacker will also be able to trick the same developer into using the right sub key the attacker is actually interested in. My point is: While I don't disagree that best practice should be an own sub key for every purpose, arguing that this has an impact on security is wrong. And that was and still is my reason why I don't want that this is getting enforced. Michał Górny wrote: > +This policy serves two purposes. Firstly, it provides a last fallback option > +in the event of access to the secret keys being lost and there being > +no possibility of revoking them. In this case, the keys eventually expire > +and users can clearly see that they are no longer being used. Secondly, it > +ensures that the developers periodically confirm their access to the primary > +key. And I am also challenging this one: Given that this a policy for Gentoo, we have to take Gentoo specifics into account: In Gentoo the primary purpose of OpenGPG is to sign commits and push operations. A git hook ensures that each commit and push is well signed by a known key. However, this key is coming from Gentoo's LDAP. LDAP is accessed via SSH key. So anyone with access to a developer's SSH key is able to add an additional (malicious) key which would be picked up by other automated processes with the result that whoever is in control of that additional key could now use it to commit and push to any Gentoo repositories. In this process, an expiration date isn't really used. Again, it is best practice but when we don't use it, why do we care and enforce such a value? Well, if you take the *now* proposed "Foreword" into account I *could* arrange with such a statement because expiration date plays a role in the web of trust and GLEP 63 seems to be more than just a OpenGPG policy for commit/push. -- Regards, Thomas Deutschmann / Gentoo Linux Developer C4DD 695F A713 8F24 2AA1 5638 5849 7EE5 1D5D 74A5
signature.asc
Description: OpenPGP digital signature
