www-infrastructure-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dennis E. Hamilton" <dennis.hamil...@acm.org>
Subject RE: Signing jars
Date Thu, 08 Sep 2011 14:09:40 GMT
I see that the signing-in-the middle is an isolated problem.  

For fun now, more armchair observations to deal with two levels of assertion of authenticity
(just in case it ever comes up [;<):

My impression of these particular embedded signature arrangements is that the unsigned artifact
is created with a "hole" for the signature.  The signature is inserted in a post-processing
step. (MSFT Code Signing I think, not sure how the Jar case is handled, because it involves
a Zip structure.  In the ODF signing, using a Zip, subsequent additional-/counter-signing
is possible even though the signature(s) are in a single META-INF/documentsignatures.xml part.)
 I gather these signings are at intermediate stages of a larger process in the case at hand.

If the original signing is done by using a vacancy left in the package, then a substitution
can be made in the same vacancy after the fact.  The substitution could resign the package
and embed within it a counter-signed form of the original signature -- provided the slot is
big enough.  When a signature is verified, the slot is excluded for obvious reasons.  But
of course, the resigning must also satisfy the platform's approach to verifying signatures.
 

The other way would be that a final resigning *procedure* would not sign an artifact for which
the earlier signing is unverifiable or the signature is not trusted.  The new signing would
entirely replace the previous ones.  The previous signatures could be preserved separately
somewhere if ever required for forensic purposes or an audit of the final signing process,
assuming the resigned artifacts are not preserved in their originally-signed form.  Since
the process happens entirely at Apache, perhaps that is the most fruitful approach to explore
further.

An unsuccessful alternative to ensuring the integrity of the release would be to provide an
external signature for the release of the collection of individually-signed components --
assuming it is some kind of packaging.  That would also solve the problem of not altering
the originally-signed pieces in any way at all (that breaks the original signing).  It wouldn't
solve the problem of the components having their signatures verified by an operating system
when they are relied on or checked individually by an user.  So this one reverts to the previously
unsolved problem.

 - Dennis

PS: I can envision these actual cases in work I am doing, so the thought experiment is not
totally waste [;<).

-----Original Message-----
From: William A. Rowe Jr. [mailto:wrowe@rowe-clan.net] 
Sent: Wednesday, September 07, 2011 19:23
To: infrastructure-dev@apache.org
Subject: Re: Signing jars

On 9/7/2011 7:29 PM, Benson Margulies wrote:
> 
> For Dennis, the general issue is that, for Eclipse, the signing of the
> jars is 'in the middle' of building out the whole release, and changes
> the jars. It's not something you can do at the end.

Or rather... something you can do at the end, by altering the artifact.
There's no such thing as a detached code sig for java or for msi/exe's.


Mime
View raw message