incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rob Weir <>
Subject Re: [VOTE] Apache OpenOffice Community Graduation Vote
Date Tue, 21 Aug 2012 03:24:29 GMT
On Mon, Aug 20, 2012 at 11:05 PM, Greg Stein <> wrote:
> On Mon, Aug 20, 2012 at 10:55 PM, Prescott Nasser <> wrote:
>> I'm sorry, I'm playing catch-up and I'm a bit unclear on the argument - Marvin said:
 "If the podling believes that ASF-endorsed binaries are a hard requirement,
>> then it seems to me that the ASF is not yet ready for AOO and will not be
>> until suitable infrastructure and legal institutions to support binary
>> releases (sterile build machines, artifact signing, etc) have been created
>> and a policy has been endorsed by the Board." Is AOO not able to determine that for
them a binary is a hard requirement for their releases (along with source code)? I would think
that ASF puts a minimum requirement on what an official release is, not a limit.  Why is there
a requirement for special infrustructure? (perhaps that is due to the size of AOO?) Speaking
just from the Lucene.Net persective, I would consider our binaries (and nuget packages) as
official - even if ASF does not specifically allow for "official releases or officially endourced
binaries" - what else would they be? They were built and put up by the same guys releasing
the source code.
> The simplest response is that source releases can be audited by (P)PMC
> members. Binary releases cannot. If they cannot be audited, then how
> can the ASF stand behind those releases? How can they state that the
> releases are free of viruses/trojans/etc, and that the binary
> precisely matches the compiled/built output of the audited source
> release?

You ask a serious question it deserves a serious answer.  This issue
faces every software distributor, not just Apache.   We verify
binaries releases in several ways:

1)  As part of the release approval process project members ensure
that they can build from the source artifact.

2) I install the RC on an isolated system and check for viruses and
other malware, and then wait for a few days, refresh the virus
signatures, and test again before releasing, to ensure that we're not
caught by a zero-day attack.

3) We would like to do code signing, as do several other projects.
The discussions with Infra on how this could be accomplished are

Of course, the same questions could be asked of each of the large
number of ASF projects that release binaries today.  I wonder how many
of them even take the precautions of #2?

Maybe my turn for a question?  How many Apache projects have released
a binary in the past 10 years?  And how many have released a binary
containing a virus or a trojan?  And how many users have downloaded
Apache source and built it?  And how many of those users then found
that their servers were compromised due to a security flaw in the
Apache  source?  In theory source code can be inspected.  In practice,
stuff happens.  Ditto for binaries.


> That is the first and hardest issue about having the ASF provide
> authenticated binaries.
> Cheers,
> -g
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message