aurora-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jake Farrell <jfarr...@apache.org>
Subject Re: [DISCUSS] Build security
Date Wed, 30 Jul 2014 17:18:32 GMT
To me that brings up the question then why use any remote dist for
development at all if we are really concerned about this being an issue?
Vendor everything (py, jar, js) in our 3rdparty dir and then we guarantee
that each dependency we use has history on why it was added and who added
it (dont think that this is the greatest idea, playing devils advocate).
This does come with a cost to git in clone speed and to the growth on the
history

-Jake


On Wed, Jul 30, 2014 at 1:09 PM, Bill Farner <wfarner@apache.org> wrote:

> FWIW the filing of the ticket was reactionary only to the availability of
> a  solution, now of the scare (i've been twitchy about this for a long
> time).
>
>
>> Is this really a rampant issue causing jars to be widely compromised
>
>
> Why wait for a publicized attack?  Since we know this presents a risk, we
> should apply known strategies to mitigate the risk.
>
> since maven central is going to ssl in the near future
>
>
> This is definitely a plus, but AFAICT doesn't help us if maven central is
> compromised.
>
>
>
> -=Bill
>
>
> On Wed, Jul 30, 2014 at 9:44 AM, Jake Farrell <jfarrell@apache.org> wrote:
>
>> +0
>>
>> Aurora-620: Is this really a rampant issue causing jars to be widely
>> compromised, great blog post, but any documentation of this exploit
>> actually occurring. To me this seems like additions that are not needed
>> especially since maven central is going to ssl in the near future.
>>
>> Aurora-616: The gradle witness plugin will test against the listed
>> dependencies in our build.gradle but it does not verify any sub
>> dependencies. It would be better for us to vendor cache all of our
>> dependencies if we are really worried about this.
>>
>> -Jake
>>
>>
>> On Wed, Jul 30, 2014 at 12:10 PM, Kevin Sweeney <kevints@apache.org>
>> wrote:
>>
>> > Hi all,
>> >
>> > Recently in the news there has been a lot of controversy regarding Maven
>> > Central's lack of HTTPS support (without a donation for an access key
>> which
>> > isn't redistributable, see [1], [2], [3] for context). While Sonatype
>> plans
>> > to deploy HTTPS for all fix it there is an exploit tool in the wild.
>> > JCenter is an alternate Maven Central mirror that contains the
>> dependencies
>> > we currently get from Maven Central. It allows free HTTPS access.
>> >
>> > I propose we immediately accept my patch [4] to switch to JCenter over
>> > HTTPS, buying us an immediate mitigation to the exploit tool in the
>> wild.
>> > Longer-term we can switch to checksum-pinning our dependencies [5],
>> which
>> > will allow us to use any Maven mirror as long as we trust our git origin
>> > servers and committers.
>> >
>> > Though it wasn't called out in the press, our Python dependencies are
>> > probably vulnerable to a similar issue and I've filed an issue [6] to
>> > investigate checksum-pinning there too.
>> >
>> > Please discuss, and if you agree please give a shipit to my review.
>> >
>> > Thanks,
>> > Kevin
>> >
>> > [1]
>> >
>> >
>> http://blog.ontoillogical.com/blog/2014/07/28/how-to-take-over-any-java-developer/
>> > [2]
>> >
>> http://blog.sonatype.com/2014/07/ssl_connectivity_for_central/#.U9kVOnVdXmE
>> > [3] https://twitter.com/bintray/status/494129921363824640
>> > [4] https://reviews.apache.org/r/24063/
>> > [5] https://issues.apache.org/jira/browse/AURORA-616
>> > [6] https://issues.apache.org/jira/browse/AURORA-618
>> >
>>
>
>

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