Gentoo Archives: gentoo-dev

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

Attachments

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