> -----Original Message----- > From: Nick Kew [mailto:[email protected]] > Sent: Tuesday, July 26, 2016 02:25 > To: [email protected] > 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 id.apache.org, 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 [email protected] 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 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: [email protected] > For additional commands, e-mail: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
