incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Martin Gainty <>
Subject RE: Code signing and WOT for releases
Date Wed, 27 Jul 2016 15:06:02 GMT

> From:
> To:
> Subject: RE: Code signing and WOT for releases
> Date: Tue, 26 Jul 2016 10:33:13 -0700
> > -----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.
> [orcmid] 
> 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!
> [orcmid] 
> 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.

MG>can we assume the key was converted to PKCS8 before asserting the key?

MG>and then built new SignatureBuilder().buildObject() Signature with key locations before
assigning assertion.setSignature(___)?

MG>/thanks dennis/
> (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
> signatures.)
> > 
> > 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:
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message