On Sat, 2018-08-04 at 16:57 +0200, Thomas Deutschmann wrote: > 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.
I defer this to Kristian. He knows the GnuPG internals much better than I do. > 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. Most of the developers are always signing their mails using their OpenPGP keys. In fact, mail signing preceded Manifest signing, not to mention the migration to git. Why would suddenly its purpose be reduced to just commits? -- Best regards, Michał Górny
signature.asc
Description: This is a digitally signed message part
