incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jake Farrell <>
Subject Re: Complications with Gradle wrapped projects and source releases (Samza, DataFu, Aurora)
Date Sun, 15 Jun 2014 12:36:37 GMT
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


On Fri, Jun 13, 2014 at 6:52 PM, Marvin Humphrey <>

> On Fri, Jun 13, 2014 at 11:14 AM, Steve Loughran <>
> wrote:
> > On 10 June 2014 16:20, Marvin Humphrey <> 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:
> For additional commands, e-mail:

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message