RE: AOO and Code Signing (was Re: [VOTE] Apache OpenOffice ... )

["Dennis E. Hamilton" <or...@apache.org>]

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 practice.  

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 integrity.

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 OpenOffice.org 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 [mailto:jim@jaguNET.com] 
Sent: Monday, August 27, 2012 11:02
To: ooo-dev@incubator.apache.org; orcmid@apache.org
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 <or...@apache.org> 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 [mailto:joe_schaefer@yahoo.com] 
> Sent: Monday, August 27, 2012 10:07
> To: general@incubator.apache.org
> Cc: ooo-dev@incubator.apache.org
> 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 <gs...@gmail.com>
>> To: general@incubator.apache.org
>> Cc: "ooo-dev@incubator.apache.org" <oo...@incubator.apache.org>
>> 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" <ji...@jagunet.com> 
>> 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:
>> 
>> https://dist.apache.org/repos/dist/release/subversion/subversion-1.7.6.tar.bz2.asc
>> 
>> Cheers,
>> -g
>> 
>