You are viewing a plain text version of this content. The canonical link for it is here.
Posted to log4cxx-dev@logging.apache.org by Thorsten Schöning <ts...@am-soft.de> on 2016/07/26 07:19:59 UTC
Code signing and WOT for releases
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].
Is there some way to check what the owner of a PGP key for former
releases has done to get his association to the WOT, if any? I would
like to understand the needed process better and e.g. found the
following:
http://pgp.surfnet.nl:11371/pks/lookup?op=vindex&fingerprint=on&search=0x2E114322
Are all those people/keys on this list someone who signed the key I
searched for and provided association with the WOT this way?
Are the mentioned possibilities in [2] the only way to get such an
association to the WOT? I usually don't visit conferences or
keysigning parties or such.
Am I correct that releases can't be published without such an
association to the WOT at all and BEFOREHAND? Else one could sign and
publish a release and loose the key afterwards or else and the release
would be left without the needed association.
Thanks!
[1]: http://incubator.apache.org/guides/releasemanagement.html#signing
[2]: http://www.apache.org/dev/openpgp.html#apache-wot-link
Mit freundlichen Grüßen,
Thorsten Schöning
--
Thorsten Schöning E-Mail: Thorsten.Schoening@AM-SoFT.de
AM-SoFT IT-Systeme http://www.AM-SoFT.de/
Telefon...........05151- 9468- 55
Fax...............05151- 9468- 88
Mobil..............0178-8 9468- 04
AM-SoFT GmbH IT-Systeme, Brandenburger Str. 7c, 31789 Hameln
AG Hannover HRB 207 694 - Geschäftsführer: Andreas Muchow
Fwd: Re: Code signing and WOT for releases
Posted by Thorsten Schöning <ts...@am-soft.de>.
Dies ist eine weitergeleitete Nachricht
Von : Mark Thomas <ma...@apache.org>
An : general@incubator.apache.org
Datum : Dienstag, 26. Juli 2016, 09:48
Betreff: Code signing and WOT for releases
===8<=================== Original Nachrichtentext ===================
On 26/07/2016 08:19, 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].
>
> Is there some way to check what the owner of a PGP key for former
> releases has done to get his association to the WOT, if any? I would
> like to understand the needed process better and e.g. found the
> following:
>
> http://pgp.surfnet.nl:11371/pks/lookup?op=vindex&fingerprint=on&search=0x2E114322
>
> Are all those people/keys on this list someone who signed the key I
> searched for and provided association with the WOT this way?
Yes.
> Are the mentioned possibilities in [2] the only way to get such an
> association to the WOT? I usually don't visit conferences or
> keysigning parties or such.
It depends on what the signer is prepared to accept as proof of
identity. In most cases, a face to face meeting is required.
> Am I correct that releases can't be published without such an
> association to the WOT at all and BEFOREHAND?
No.
The release manager's key MUST be added to the project's KEY file
*before* signing the release.
The release manager MUST upload their key to a public key server (e.g.
pgp.mit.edu) *before* signing the release
Releases MUST be signed.
The release manager SHOULD add their key to their profile on id.apache.org
The release manager SHOULD add their key to the ASF WoT at the earliest
opportunity. If you don't visit conferences then one option is to use
[3] to find a nearby committer who might be able to sign your key.
HTH,
Mark
> Else one could sign and
> publish a release and loose the key afterwards or else and the release
> would be left without the needed association.
>
> Thanks!
>
> [1]: http://incubator.apache.org/guides/releasemanagement.html#signing
> [2]: http://www.apache.org/dev/openpgp.html#apache-wot-link
[3] http://community.zones.apache.org/map.html
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
===8<============== Ende des Original Nachrichtentextes =============
Hallo,
Mit freundlichen Grüßen,
Thorsten Schöning
--
Thorsten Schöning E-Mail: Thorsten.Schoening@AM-SoFT.de
AM-SoFT IT-Systeme http://www.AM-SoFT.de/
Telefon...........05151- 9468- 55
Fax...............05151- 9468- 88
Mobil..............0178-8 9468- 04
AM-SoFT GmbH IT-Systeme, Brandenburger Str. 7c, 31789 Hameln
AG Hannover HRB 207 694 - Geschäftsführer: Andreas Muchow
Re: Code signing and WOT for releases
Posted by Mark Thomas <ma...@apache.org>.
On 26/07/2016 08:19, 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].
>
> Is there some way to check what the owner of a PGP key for former
> releases has done to get his association to the WOT, if any? I would
> like to understand the needed process better and e.g. found the
> following:
>
> http://pgp.surfnet.nl:11371/pks/lookup?op=vindex&fingerprint=on&search=0x2E114322
>
> Are all those people/keys on this list someone who signed the key I
> searched for and provided association with the WOT this way?
Yes.
> Are the mentioned possibilities in [2] the only way to get such an
> association to the WOT? I usually don't visit conferences or
> keysigning parties or such.
It depends on what the signer is prepared to accept as proof of
identity. In most cases, a face to face meeting is required.
> Am I correct that releases can't be published without such an
> association to the WOT at all and BEFOREHAND?
No.
The release manager's key MUST be added to the project's KEY file
*before* signing the release.
The release manager MUST upload their key to a public key server (e.g.
pgp.mit.edu) *before* signing the release
Releases MUST be signed.
The release manager SHOULD add their key to their profile on id.apache.org
The release manager SHOULD add their key to the ASF WoT at the earliest
opportunity. If you don't visit conferences then one option is to use
[3] to find a nearby committer who might be able to sign your key.
HTH,
Mark
> Else one could sign and
> publish a release and loose the key afterwards or else and the release
> would be left without the needed association.
>
> Thanks!
>
> [1]: http://incubator.apache.org/guides/releasemanagement.html#signing
> [2]: http://www.apache.org/dev/openpgp.html#apache-wot-link
[3] http://community.zones.apache.org/map.html
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
RE: Code signing and WOT for releases
Posted by Martin Gainty <mg...@hotmail.com>.
> From: orcmid@apache.org
> To: general@incubator.apache.org
> Subject: RE: Code signing and WOT for releases
> Date: Thu, 28 Jul 2016 10:05:05 -0700
>
>
>
> > -----Original Message-----
> > From: Martin Gainty [mailto:mgainty@hotmail.com]
> > Sent: Thursday, July 28, 2016 05:13
> > To: general@incubator.apache.org
> > Subject: RE: Code signing and WOT for releases
> >
> > 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 orcmid@apache.org[orcmid] if you are *not*
> > using assertions how would this be accomplished?
> [orcmid]
> That's correct, there is no technical assertion mechanism in OpenPGP. I should not have used that term.
MG>apologies from my end but the build engineer in me wants to see if all these steps can be automated
>
> What constitutes the equivalent of an *attestation* in WOT is the counter-signing of a public key by another. That is taken as an attestation that an identified individual claimed authority over the private key by virtue of the fingerprint, the User ID, and in-person confirmation of identification.
>
> In the case of controlling orcmid@ apache.org, the evidence is that the person having control of that account (Apache Committer ID orcmid) placed the fingerprint in his private account record and the system retrieved the key with that fingerprint and placed it at <http://people.apache.org/keys/committer/orcmid.asc>.
mg>these are covered by gpg plugin attributes for maven @ http://maven.apache.org/plugins/maven-gpg-plugin/sign-mojo.html
That is retrieval from Internet key servers periodically and will reflect any counter-signing by others as well as any revocation.
mg> unfortunately in my builds CRL attestations are handled by a JSSE code (assuming an non-self-signed X509 cert does exist) > There's more to be said about that particular certificate, and other attestations that apply to it, but we can stop here unless you are curious about that.
MG>yes I would
>
> - Dennis
>
> >
MG> Thanks Dennis,
MG> Martin
> > ______________________________________________
> >
> >
> >
> > > From: dennis.hamilton@acm.org
> > > To: general@incubator.apache.org
> > > Subject: RE: Code signing and WOT for releases
> > > Date: Wed, 27 Jul 2016 10:01:59 -0700
> > >
> > >
> > > > -----Original Message-----
> > > > From: Martin Gainty [mailto:mgainty@hotmail.com]
> > > > Sent: Wednesday, July 27, 2016 08:06
> > > > To: general@incubator.apache.org
> > > > Subject: RE: Code signing and WOT for releases
> > > >
> > > >
> > > >
> > > > > From: dennis.hamilton@acm.org
> > > > > To: general@incubator.apache.org
> > > > > Subject: RE: Code signing and WOT for releases
> > > > > Date: Tue, 26 Jul 2016 10:33:13 -0700
> > > > > [ ... ] 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 orcmid@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/
> > > [orcmid]
> > >
> > > This signing had nothing to do with MIME-signatures or SSL. It is a
> > plaintext message that has a "clearsign" OpenPGP signed section in-line
> > in the message body. (The signed part was created first and then pasted
> > into the plaintext email.) You can see the archived form at
> > > <http://mail-archives.apache.org/mod_mbox/openoffice-
> > announce/201607.mbox/browser> where it is the only message there. At the
> > bottom of the HTML-formatted display of the message, select the "Unnamed
> > text/plain" link to see a cleaner plaintext.
> > >
> > > This is not unlike the .asc files that can be made as external PGP
> > signatures of code, except it is inline instead of external to the file
> > being signed.
> > >
> > > > >
> > > > > (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.)
> > > [orcmid]
> > >
> > > (If you look at the raw version on the archive, you will see a pile of
> > =20 line endings that make the raw form unverifiable. And because the
> > signature block has a line ending in =, there is an appended raw "3D"
> > that breaks the whole thing. A client that does not restore the
> > plaintext before checking the signature will claim that the signature is
> > "BAD".)
> > >
> > > PS: I sent the same message to a colleague who has a PGP-aware email
> > client, and the message verified automatically and was presented without
> > the boundaries and the signature block. Instead, there was a marker
> > that indicated the part of the message that was signed. So it would
> > appear that the person who reported to me encountered an
> > interoperability failure.
> > > > >
> > > [ ... ]
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> > > For additional commands, e-mail: general-help@incubator.apache.org
> > >
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
RE: Code signing and WOT for releases
Posted by "Dennis E. Hamilton" <or...@apache.org>.
> -----Original Message-----
> From: Martin Gainty [mailto:mgainty@hotmail.com]
> Sent: Thursday, July 28, 2016 05:13
> To: general@incubator.apache.org
> Subject: RE: Code signing and WOT for releases
>
> 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 orcmid@apache.org[orcmid] if you are *not*
> using assertions how would this be accomplished?
[orcmid]
That's correct, there is no technical assertion mechanism in OpenPGP. I should not have used that term.
What constitutes the equivalent of an *attestation* in WOT is the counter-signing of a public key by another. That is taken as an attestation that an identified individual claimed authority over the private key by virtue of the fingerprint, the User ID, and in-person confirmation of identification.
In the case of controlling orcmid@ apache.org, the evidence is that the person having control of that account (Apache Committer ID orcmid) placed the fingerprint in his private account record and the system retrieved the key with that fingerprint and placed it at <http://people.apache.org/keys/committer/orcmid.asc>. That is retrieval from Internet key servers periodically and will reflect any counter-signing by others as well as any revocation.
There's more to be said about that particular certificate, and other attestations that apply to it, but we can stop here unless you are curious about that.
- Dennis
>
> Regards
> Martin
> ______________________________________________
>
>
>
> > From: dennis.hamilton@acm.org
> > To: general@incubator.apache.org
> > Subject: RE: Code signing and WOT for releases
> > Date: Wed, 27 Jul 2016 10:01:59 -0700
> >
> >
> > > -----Original Message-----
> > > From: Martin Gainty [mailto:mgainty@hotmail.com]
> > > Sent: Wednesday, July 27, 2016 08:06
> > > To: general@incubator.apache.org
> > > Subject: RE: Code signing and WOT for releases
> > >
> > >
> > >
> > > > From: dennis.hamilton@acm.org
> > > > To: general@incubator.apache.org
> > > > Subject: RE: Code signing and WOT for releases
> > > > Date: Tue, 26 Jul 2016 10:33:13 -0700
> > > > [ ... ] 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 orcmid@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/
> > [orcmid]
> >
> > This signing had nothing to do with MIME-signatures or SSL. It is a
> plaintext message that has a "clearsign" OpenPGP signed section in-line
> in the message body. (The signed part was created first and then pasted
> into the plaintext email.) You can see the archived form at
> > <http://mail-archives.apache.org/mod_mbox/openoffice-
> announce/201607.mbox/browser> where it is the only message there. At the
> bottom of the HTML-formatted display of the message, select the "Unnamed
> text/plain" link to see a cleaner plaintext.
> >
> > This is not unlike the .asc files that can be made as external PGP
> signatures of code, except it is inline instead of external to the file
> being signed.
> >
> > > >
> > > > (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.)
> > [orcmid]
> >
> > (If you look at the raw version on the archive, you will see a pile of
> =20 line endings that make the raw form unverifiable. And because the
> signature block has a line ending in =, there is an appended raw "3D"
> that breaks the whole thing. A client that does not restore the
> plaintext before checking the signature will claim that the signature is
> "BAD".)
> >
> > PS: I sent the same message to a colleague who has a PGP-aware email
> client, and the message verified automatically and was presented without
> the boundaries and the signature block. Instead, there was a marker
> that indicated the part of the message that was signed. So it would
> appear that the person who reported to me encountered an
> interoperability failure.
> > > >
> > [ ... ]
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> > For additional commands, e-mail: general-help@incubator.apache.org
> >
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
RE: Code signing and WOT for releases
Posted by Martin Gainty <mg...@hotmail.com>.
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 orcmid@apache.orgif you are *not* using assertions how would this be accomplished?
Regards
Martin
______________________________________________
> From: dennis.hamilton@acm.org
> To: general@incubator.apache.org
> Subject: RE: Code signing and WOT for releases
> Date: Wed, 27 Jul 2016 10:01:59 -0700
>
>
> > -----Original Message-----
> > From: Martin Gainty [mailto:mgainty@hotmail.com]
> > Sent: Wednesday, July 27, 2016 08:06
> > To: general@incubator.apache.org
> > Subject: RE: Code signing and WOT for releases
> >
> >
> >
> > > From: dennis.hamilton@acm.org
> > > To: general@incubator.apache.org
> > > Subject: RE: Code signing and WOT for releases
> > > Date: Tue, 26 Jul 2016 10:33:13 -0700
> > > [ ... ] 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 orcmid@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/
> [orcmid]
>
> This signing had nothing to do with MIME-signatures or SSL. It is a plaintext message that has a "clearsign" OpenPGP signed section in-line in the message body. (The signed part was created first and then pasted into the plaintext email.) You can see the archived form at
> <http://mail-archives.apache.org/mod_mbox/openoffice-announce/201607.mbox/browser> where it is the only message there. At the bottom of the HTML-formatted display of the message, select the "Unnamed text/plain" link to see a cleaner plaintext.
>
> This is not unlike the .asc files that can be made as external PGP signatures of code, except it is inline instead of external to the file being signed.
>
> > >
> > > (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.)
> [orcmid]
>
> (If you look at the raw version on the archive, you will see a pile of =20 line endings that make the raw form unverifiable. And because the signature block has a line ending in =, there is an appended raw "3D" that breaks the whole thing. A client that does not restore the plaintext before checking the signature will claim that the signature is "BAD".)
>
> PS: I sent the same message to a colleague who has a PGP-aware email client, and the message verified automatically and was presented without the boundaries and the signature block. Instead, there was a marker that indicated the part of the message that was signed. So it would appear that the person who reported to me encountered an interoperability failure.
> > >
> [ ... ]
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
RE: Code signing and WOT for releases
Posted by "Dennis E. Hamilton" <de...@acm.org>.
> -----Original Message-----
> From: Martin Gainty [mailto:mgainty@hotmail.com]
> Sent: Wednesday, July 27, 2016 08:06
> To: general@incubator.apache.org
> Subject: RE: Code signing and WOT for releases
>
>
>
> > From: dennis.hamilton@acm.org
> > To: general@incubator.apache.org
> > Subject: RE: Code signing and WOT for releases
> > Date: Tue, 26 Jul 2016 10:33:13 -0700
> > [ ... ] 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 orcmid@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/
[orcmid]
This signing had nothing to do with MIME-signatures or SSL. It is a plaintext message that has a "clearsign" OpenPGP signed section in-line in the message body. (The signed part was created first and then pasted into the plaintext email.) You can see the archived form at
<http://mail-archives.apache.org/mod_mbox/openoffice-announce/201607.mbox/browser> where it is the only message there. At the bottom of the HTML-formatted display of the message, select the "Unnamed text/plain" link to see a cleaner plaintext.
This is not unlike the .asc files that can be made as external PGP signatures of code, except it is inline instead of external to the file being signed.
> >
> > (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.)
[orcmid]
(If you look at the raw version on the archive, you will see a pile of =20 line endings that make the raw form unverifiable. And because the signature block has a line ending in =, there is an appended raw "3D" that breaks the whole thing. A client that does not restore the plaintext before checking the signature will claim that the signature is "BAD".)
PS: I sent the same message to a colleague who has a PGP-aware email client, and the message verified automatically and was presented without the boundaries and the signature block. Instead, there was a marker that indicated the part of the message that was signed. So it would appear that the person who reported to me encountered an interoperability failure.
> >
[ ... ]
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
RE: Code signing and WOT for releases
Posted by Martin Gainty <mg...@hotmail.com>.
> From: dennis.hamilton@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:niq@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 orcmid@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-unsubscribe@incubator.apache.org
> > For additional commands, e-mail: general-help@incubator.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
RE: Code signing and WOT for releases
Posted by "Dennis E. Hamilton" <de...@acm.org>.
> -----Original Message-----
> From: Nick Kew [mailto:niq@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 orcmid@apache.org 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: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Code signing and WOT for releases
Posted by Nick Kew <ni...@apache.org>.
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.
Yes, also the project's KEYS and id.apache.org, but that's
a separate issue to the WoT!
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-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org