thinking about this, hadoop branch-1 used to GET ivy.jar, didn't it?
On 16 June 2014 10:46, Jakob Homan <jgho...@gmail.com> wrote: > We've gone ahead and built a separate build script that will bootstrap a > source release. (https://issues.apache.org/jira/browse/SAMZA-283). This > works but is a bit clunky. > > -jakob > > > > On Sun, Jun 15, 2014 at 9:38 AM, abiola balogun <a_gucc...@me.com> wrote: > > > So what now? > > > > Sent from my iPhone > > > > > On Jun 15, 26 Heisei, at 20:36, Jake Farrell <jfarr...@apache.org> > > wrote: > > > > > > Hey Marvin > > > That is correct, gradle.jar is the only binary and that is able to be a > > > fixed repeatable build via a wrapper task in the build.gradle file. > After > > > re-reading the policies I'm in agreement with them and dont think that > we > > > need to make an exception for this. Each project can create a secondary > > > binary release package which includes this file and the repo can still > > have > > > it committed (which is the big benefit for it since it makes the > initial > > > development bootstrapping a little nicer). This is no different than > what > > > projects like Ant and Maven have been doing for some time now and I > think > > > is the better approach > > > > > > -Jake > > > > > > > > > > > > On Fri, Jun 13, 2014 at 6:52 PM, Marvin Humphrey < > mar...@rectangular.com > > > > > > wrote: > > > > > >> On Fri, Jun 13, 2014 at 11:14 AM, Steve Loughran < > > ste...@hortonworks.com> > > >> wrote: > > >>> On 10 June 2014 16:20, Marvin Humphrey <mar...@rectangular.com> > wrote: > > >>> > > >>>> One fundamental problem with compiled deps is that unlike source > code, > > >> they > > >>>> cannot be reviewed by a PMC -- so they are potential trojan horses. > > >> Maybe > > >>>> it's possible to address that specific concern by compiling an ASF > > >>>> whitelist of individual jar files whose provenance can be guaranteed > > and > > >>>> whose identity is verified via PGP prior to committing? > > >>> > > >>> true, but who does a transitive validation of all mvn/ivy > dependencies, > > >>> validating the checksums from an HTTPS server while pulling them down > > >> from > > >>> a normal HTTP link. Were I to perform a MITM intercept of maven > central > > >>> DNS/GETs at something like apachecon, I'd probably have everyone's > > >>> password-less ssh keys within 48 hours. > > >> > > >> If I'm understanding the Gradle situation right, the task at hand is > > more > > >> limited: to get the Gradle wrapper alone into version control. There > > >> seems to > > >> be a closed set of files which we could build from source in a > > >> controlled environment, sign with PGP keys, and archive somewhere. > > >> > > >> Extrapolating out to arbitrary dependencies and arbitrary build > systems > > is > > >> a > > >> worthwhile exercise when considering the potential for org-certified > > >> binaries -- is it feasible to assemble a collection of certified > > >> dependencies > > >> and use those in conjunction with disposable build servers running > > offline > > >> to > > >> compile releases securely? But that's a much bigger topic. > > >> > > >> Marvin Humphrey > > >> > > >> --------------------------------------------------------------------- > > >> 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 > > > > > -- CONFIDENTIALITY NOTICE NOTICE: This message is intended for the use of the individual or entity to which it is addressed and may contain information that is confidential, privileged and exempt from disclosure under applicable law. If the reader of this message is not the intended recipient, you are hereby notified that any printing, copying, dissemination, distribution, disclosure or forwarding of this communication is strictly prohibited. If you have received this communication in error, please contact the sender immediately and delete it from your system. Thank You.
