incubator-ooo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dave Fisher <dave2w...@comcast.net>
Subject Re: [VOTE] Apache OpenOffice Community Graduation Vote
Date Sun, 26 Aug 2012 20:04:24 GMT

On Aug 26, 2012, at 12:54 PM, Dave Fisher wrote:

> 
> On Aug 26, 2012, at 12:42 PM, Dennis E. Hamilton wrote:
> 
>> FYI, concerning the matter of binaries distributed by the Apache OpenOffice project.
>> 
>> I neglected to consider a case that Dave Fisher just raised here on ooo-dev: Where
the binary dependencies relied upon in an Apache OpenOffice binary distribution are accessed
from at build time and where those are identifiably preserved for purposes of replication/confirmation
and also for any future forensic need.  That is an element in my topic (2) below.
> 
> Before we all light our hair on fire. I'm only saying that the build must not pull these
out of svn, even as a backup. If you examine the current scripts that has been done already.

Correction - the scripts go to external sources first. I am prosing to take away the svn fallback.

> 
> Regards,
> Dave
> 
>> 
>> Please do not comment on the general@ i.a.o thread.  It is a zombie in the process
of being burned at the stake.
>> 
>> - Dennis
>> 
>> -----Original Message-----
>> From: Dennis E. Hamilton [mailto:orcmid@apache.org] 
>> Sent: Sunday, August 26, 2012 12:12
>> To: general@incubator.apache.org
>> Subject: RE: [VOTE] Apache OpenOffice Community Graduation Vote
>> 
>> Since my post was mentioned later on this thread, I thought I would summarize what
I have as the take-away from intervening discussion.  I have no intention to deal with the
use of language (i.e., semantics of "convenience") and the way that tacit policy understanding
is conveyed among Apache project participants.
>> 
>> I will also refrain from any further additions to this topic.
>> 
>> TAKE-AWAYS
>> 
>> With regard to the production and delivery to users of authentic Apache OpenOffice
binary builds, there seem to be the following concerns (especially for, but not limited to,
Windows and Apple binaries and aggravated further by the restraints that are growing around
evolving "App Store" requirements for consumer- and cloud-oriented platforms).  I see three
cases:
>> 
>>  1. Authentication of binaries
>>  2. Provenance of bundled binary dependencies 
>>  3. Availability of source for inspection, audit, and provenance
>> 
>> 1. AUTHENTICATION OF BINARIES
>> 
>> The desire for binaries to be signed using digital signatures with private keys held
by the ASF is a natural concern for authentication of a variety of binaries produced by Apache
projects.
>> 
>> There appears to be agreement that any such signature introductions must be done
by ASF-authorized agents.  The conclusion is that infrastructure would perform such signings.
 These signings, by virtue of their modification of the unsigned binary, will invalidate any
external signatures that were prepared as part of the release process.  (It is possible to
extract the internal signature and verify an external signature, if that is ever any question
about that.)
>> 
>> The signing party would have the reliance of the release-manager external signatures
and other attestation that the binary is produced from the release sources.
>> 
>> This still leaves open additional concerns about the conditions under which the binaries
are produced and any difficulties that result.
>> 
>> An alternative is for the signing authority to also produce the binaries, using the
release sources directly on secured build machines.  There are a number of technical problems
that arise in this case, unless the release candidates were built in the same manner but not
(yet) signed.  That could work.  It would also confirm that the binaries are indeed produced
from the release's sources using the parameters for the platform presumably also included
in the source materials.
>> 
>> The remaining question is, what is being attested to by the production of binaries
that are authenticated in this manner? Simply that they have been built in this manner and
that it was done using ASF infrastructure, the integrity of which the ASF can be accountable
for.  It is not an attestation that there are no bugs, no security defects, or even that the
IP provenance is assured to be clean.  It is that the binary was produced under these particular
verifiable conditions from the source materials provided as part of the source release along
with dependencies on binaries incorporated in the build.  
>> 
>> It also provides a strong differentiator for binaries, however they might be identified,
including even release candidates and developer builds, that were not provided in this manner.
>> 
>> 2. PROVENANCE OF BUNDLED BINARY DEPENDENCIES
>> 
>> A complication in (1) is the incorporation of binary resources on which the source-code
release depends in order to be built.  These might be authorized (and usually authenticated)
redistributables having closed-source origins.  These might be authorized open-source libraries
that must be used without construction from sources in order for authentication of the dependency
to be preserved.  (E.g., there are security libraries that have NIST certification on the
binary library, never the source, and the certification is also sustained only when the library
is used with specific tooling.)
>> 
>> For whatever reason, it is appropriate and preferable that the binary form of a dependency
be relied upon, whether a jar file, a static library, or a dynamic library (DLL or SO) that
becomes incorporated in the authenticated binary.
>> 
>> The specific dependencies of such a nature would need to be accounted for as part
of the authenticated build.  That requires more traceability to specific artifacts and the
basis for their reliance in some manner that does not involve building of the dependencies
from sources as part of the build.  This would probably require additional rigorous treatment
to satisfy requirements for the integrity of the ASF project build.  It might take more than
simple reliance on the asserted IP and provenance of the upstream-obtained binaries.  I am
thinking that one needs to be specific to the artifact level, at least.
>> 
>> 3. AVAILABILITY OF SOURCE FOR INSPECTION, AUDIT, AND PROVENANCE
>> 
>> On this thread, the importance of having source code available has been stated as
a strong requirement.  As far as I can tell, this is a requirement for IP provenance more
than anything else.  
>> 
>> Of course, the good-faith reliance on upstream sources always comes to bear, even
for source-code contributions.  But having access to all source is reported by some as being
essential for ASF releases and that is tied to the notion that the source code is the release.
 (This is despite specific provision in the treatment of licenses for distributing certain
binary artifacts in order to avoid license confusion.)
>> 
>> I don't have any clarity on this.  I know that it would be a serious burden to some
projects if there were restriction to authenticated builds for open-source platforms only
and/or restriction to exclusively open-source libraries for other dependencies not satisfied
by the platform itself.  
>> 
>> To the extent that the requirement is for more than IP provenance and license reconciliation,
I am not clear who is being held to account for any deeper scrutiny than that.  Are the PMC
votes for a release expected to establish some sort of serious attestation concerning the
nature of the source?  
>> 
>> Instead, is the requirement of specific source-code availability instead a requirement
for potential forensic requirements later in the lifecycle of a release?  Can this be satisfied
without the source be in the release, by whatever arrangement and assurance that could be
made to ensure its availability whenever needed?
>> 
>> I have only question in this area.  I believe there is a definite concern, but I
am not sure where it has teeth beyond a ritual requirement.
>> 
>> - Dennis
>> 
>> 
>> -----Original Message-----
>> From: Dennis E. Hamilton [mailto:orcmid@apache.org] 
>> Sent: Monday, August 20, 2012 18:50
>> To: general@incubator.apache.org
>> Subject: RE: [VOTE] Apache OpenOffice Community Graduation Vote
>> 
>> I do not dispute the existence of other reliable creators of binary distributions.
 The *nix packagings and installation in consumer desktops are notable for the value that
they provide.  
>> 
>> I think that experience teaches us that there absolutely needs to be a way to obtain
and install *authentic* binary distributions made using the release sources with a proper
set of options for a given platform.
>> 
>> It is near impossible to provide end-user support and bug confirmation without agreement
on the authentic bindist that is being use and that it is a bindist made from known sources.
>> 
>> And there are enough fraudulent distributions out there that this is critical as
a way to safeguard users.
>> 
>> For that reason alone, there needs to be an authenticated bindist, especially for
Windows, the 80% that garners the focused attention of miscreants and opportunists.  
>> 
>> That is also the reason for wanting signed binaries that pass verification on Windows
and OS X.  There needs to be a way for everyday users to receive every assurance that they
are installing an authentic bindist and that it is verifiable who the origin is.  I suspect
that reliable packagers of unique distributions (including any from IBM) will provide their
own verifiable authenticity.
>> 
>> - Dennis
>> 
>> -----Original Message-----
>> From: drew [mailto:drew@baseanswers.com] 
>> Sent: Monday, August 20, 2012 18:00
>> To: general@incubator.apache.org
>> Subject: Re: [VOTE] Apache OpenOffice Community Graduation Vote
>> 
>> [ ... ]
>> 
>> 
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>> For additional commands, e-mail: general-help@incubator.apache.org
>> 
> 


Mime
View raw message