incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From abiola balogun <>
Subject Re: Complications with Gradle wrapped projects and source releases (Samza, DataFu, Aurora)
Date Sun, 15 Jun 2014 16:38:59 GMT
So what now?

Sent from my iPhone

> On Jun 15, 26 Heisei, at 20:36, Jake Farrell <> 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 <>
> wrote:
>> 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:

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

View raw message