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 |