Re: [gentoo-dev] [PATCH 0/3] GLEP 63: rationale part

[Thomas Deutschmann]

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.


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.


-- 
Regards,
Thomas Deutschmann / Gentoo Linux Developer
C4DD 695F A713 8F24 2AA1 5638 5849 7EE5 1D5D 74A5