incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dennis E. Hamilton" <>
Subject RE: Code signing and WOT for releases
Date Tue, 26 Jul 2016 17:33:13 GMT

> -----Original Message-----
> From: Nick Kew []
> Sent: Tuesday, July 26, 2016 02:25
> To:
> Subject: Re: Code signing and WOT for releases
> On Tue, 2016-07-26 at 09:19 +0200, Thorsten Schöning wrote:
> > Hi all,
> >
> > the docs about release management for incubating projects make clear
> > that the release needs to be signed[1] and in the end associated with
> > the project AND the WOT of Apache in general[2].
> I don't like that term "the WOT of Apache in general", with its
> implied suggestion that an Apache WoT might differ from AN Other.
> Even if a private Apache WoT were a reality, how would that help
> our users verify our releases?  Surely the WoT we should be
> concerned with is the Strong Set that unifies Geekdom at large.

I think that is perhaps relevant to how the WoT is viewed, but it does not necessarily consider
the audience of the signed material.  

For example, Apache OpenOffice distributes binaries on behalf of end-users.  They are unlikely
to know anyone in the WoT of a signer and, while there may be an effect in numbers, it is
not clear how one can be satisfied abut the identity and veracity of the signer.

Also, there are two aspects that seem to be muddled in discussion of the WoT.  There is how
much one trusts that the private key is in the exclusive control of the user identified in
the public key certificate and that the identification is accurate, and the not-quite-the-same
question of how much one trusts the possessor of that private key to be careful in the counter-signing
of the public keys of others.  

> Yes, also the project's KEYS and, but that's
> a separate issue to the WoT!

Right.  Yesterday, I received an email from one of the users who received a security advisory
message that I signed.  The user's mail reader reported that the signature was untrusted (no
surprise) and that the signature was BAD.  Since the mail reader shows the stripped message,
and it looks perfectly fine, there is no way to help analyze that from my end.

What I did do was (1) verify the message that was sent to me from the list and (2) verify
the message in the list archive.  I then (3) advised the recipient what I did and also (4)
how to find a public key certificate matching the ID in the signature and how to check that
the private key is asserted to be in the possession of the person controlling
and how the individual having control of that email address is associated with the ASF.

(I made another check of the archived message too.  The raw form of the message fails to verify
when downloaded and that appears to be on account of some encoding features that have to be
processed properly for the original text to be reconstituted properly. That might or might
not be relevant to how that recipient's email reader handles PGP

> In terms of instructions I can't improve on Mark's reply.
> I would add that it's not entirely unprecedented to sign a
> release with a key that can't be verified in the Strong Set,
> but you should make all efforts to avoid that.  A key that
> can't be verified adds no more security than an MD5 checksum.
> --
> Nick Kew
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message