On Mon, Aug 20, 2012 at 11:05 PM, Greg Stein <gst...@gmail.com> wrote: > On Mon, Aug 20, 2012 at 10:55 PM, Prescott Nasser <geobmx...@hotmail.com> > 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 ongoing. 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. -Rob > That is the first and hardest issue about having the ASF provide > authenticated binaries. > > Cheers, > -g > > --------------------------------------------------------------------- > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > For additional commands, e-mail: general-h...@incubator.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org