Gentoo Archives: gentoo-dev

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


File name MIME type
signature.asc application/pgp-signature


Subject Author
Re: [gentoo-dev] [PATCH 0/3] GLEP 63: rationale part "Michał Górny" <mgorny@g.o>