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. |
7 |
|
8 |
I agree but nevertheless I appreciate that someone (Michał in this case) |
9 |
doesn't rest and continue to improve things. |
10 |
|
11 |
|
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]_. |
19 |
|
20 |
I challenge this one: |
21 |
|
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. |
26 |
|
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. |
31 |
|
32 |
|
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. |
40 |
|
41 |
And I am also challenging this one: |
42 |
|
43 |
Given that this a policy for Gentoo, we have to take Gentoo specifics |
44 |
into account: |
45 |
|
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. |
54 |
|
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? |
57 |
|
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. |
62 |
|
63 |
|
64 |
-- |
65 |
Regards, |
66 |
Thomas Deutschmann / Gentoo Linux Developer |
67 |
C4DD 695F A713 8F24 2AA1 5638 5849 7EE5 1D5D 74A5 |