> From: dennis.hamil...@acm.org > To: general@incubator.apache.org > Subject: RE: Code signing and WOT for releases > Date: Tue, 26 Jul 2016 10:33:13 -0700 > > > > > -----Original Message----- > > From: Nick Kew [mailto:n...@apache.org] > > Sent: Tuesday, July 26, 2016 02:25 > > To: general@incubator.apache.org > > 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 orc...@apache.org > 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? http://stackoverflow.com/questions/5230942/how-to-read-a-private-key-for-use-with-opensaml MG>and then built new SignatureBuilder().buildObject() Signature with key locations before assigning assertion.setSignature(___)?http://www.programcreek.com/java-api-examples/index.php?api=org.opensaml.xml.signature.Signature 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: general-unsubscr...@incubator.apache.org > > For additional commands, e-mail: general-h...@incubator.apache.org > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > For additional commands, e-mail: general-h...@incubator.apache.org >
