incubator-ooo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dennis E. Hamilton" <>
Subject RE: AOO and Code Signing (was Re: [VOTE] Apache OpenOffice ... )
Date Mon, 27 Aug 2012 19:17:16 GMT
Great question, Jim,

1. The first substantial difference is that the operating system that runs the binary installer
*always* and automatically checks the embedded signature and warns users when there is no
such signature or when the signature is not from a trusted source (in the PKI Certificate
Authority sense) or, of course, when the signature does not verify.  Download utilities can
also verify signatures without needing to be party to any special out-of-band signature-checking

This is different than a web of trust that is centered around ASF committers who use OpenPGP
signatures and that require super-user skills to arrange to check independently.  Also, the
ASF signature practice applies to the top-level container (whether the source package or a
binary package) and not to any of the interior components, leading to (2):

2. The second substantial difference is that embedded signature(s) remain with the individual
binary artifact(s) (i.e., the installed .exe, .dll, and other artifacts that have provision
for embedded signatures).  That is, it is not just the wrapper (e.g., the msi installer file)
of the binary download that is signed, but signable components that are extracted, installed,
and registered with the system. 

After that, it is possible for an user to ask to check the signature on an artifact simply
by opening the Properties dialog on a file-system entry.  For various security conditions,
signatures will also be checked dynamically and also by intrusion-detection software. 

3. These signatures also have expirations and there is provision to check for certificate
revocation.  There are ways that can work with OpenPGP although I don't happen know how that
is supported with the ASF committer signatures. In the case of embedded signatures, certificates
can be checked for revocation or expiration at any time.  Finally, there is the ability to
have time-service counter-signatures that tighten the non-repudiation aspects.  These provisions
are second-order to the key feature, which is automatic artifact-level authentication and

The ASF approach does not fit into these regimes, which apply to Microsoft binary artifacts,
signed Java jars, Apple OS X installs, Adobe AIR apps, etc., etc.

I am not arguing that the ASF should accommodate these arrangements.  If I used "requirement"
it was not about anything to do with ASF but what platform providers are increasingly requiring
for certification of installable binaries.  (It came up around AOOi when certification for
Windows 8 was investigated.)  

I simply want to make it clear what these signing arrangements are and how they differ from
what ASF uses as an internal control and as a way to manually obtain a check on the integrity
of a download.  

 - Dennis

Of course, an independent packager could do all of this using a custom build chain.  The Sun/Oracle-packaged binaries were signed in this manner.  My downloads of TortoiseSVN for Windows
x86 and x64 configurations are all signed in this manner by their creator, Stefan Kueng. 
I am pleased to see that.  I even send money on occasion. By the way, the accompanying Tortoise
SVN certificate indicates what is being attested to by the presence of the signature.  In
the Tortoise SVN case it is to ensure software came from the software publisher and to protect
the software from alteration after publication.  That is all.

-----Original Message-----
From: Jim Jagielski [] 
Sent: Monday, August 27, 2012 11:02
Subject: Re: [VOTE] Apache OpenOffice Community Graduation Vote

And so I get back to my question... How is this new "requirement" substantially
different from the kind of signing we do today?

And please notice the word "substantially".

On Aug 27, 2012, at 1:52 PM, Dennis E. Hamilton <> wrote:

> There is a missing distinction here.
> The discussion about signed binaries is not about external signatures of the kind used
by release managers and others, nor about the external digests and signatures that might be
obtained in conjunction with a download.
> The signing of code that I am talking about, and that others are talking about (at least
in part), has to do with embedded signatures that consumer operating systems notice and check
and that are part of the artifact.  These signatures are used (and typically required for
application certification) by Microsoft, Apple, Adobe, and others.  The requirement for them
is not decreasing.
> The discussion with regard to trust and the presumed reputation of the signer has merit,
but it is not satisfied by external signatures in the case of download distributions to modern
consumer platforms.
> - Dennis
> PS: I love it that when recognized authorities ask that a discussion be moved off of
a particular list and then everyone piles on that list with a vengeance.  This message is
*not* being copied to general@ i.a.o.  
> -----Original Message-----
> From: Joe Schaefer [] 
> Sent: Monday, August 27, 2012 10:07
> To:
> Cc:
> Subject: Re: [VOTE] Apache OpenOffice Community Graduation Vote
> Which better agrees with written policy anyway- the sigs
> are part of the release package to be voted on and voted on
> by the PMC, so even though it constitutes individual sigs
> those sigs (well at least the RM's sig) are PMC-approved.
> ----- Original Message -----
>> From: Greg Stein <>
>> To:
>> Cc: "" <>
>> Sent: Monday, August 27, 2012 1:03 PM
>> Subject: Re: [VOTE] Apache OpenOffice Community Graduation Vote
>> On Aug 27, 2012 9:57 AM, "Jim Jagielski" <> 
>> wrote:
>>> ...
>>> But recall in all this that even when the PMC releases code, it is
>>> signed by the individual RM, and not by the PMC itself.
>> Apache Subversion releases tend to have a half-dozen signatures. Thus, I'd
>> say they are signed by the PMC. For example:
>> Cheers,
>> -g

View raw message