aurora-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kevin Sweeney <kevi...@apache.org>
Subject Re: [DISCUSS] Build security
Date Wed, 30 Jul 2014 17:23:56 GMT
Checksum pinning allows us to mitigate the security issues without needing
to run expensive mirroring infrastructure ourselves


On Wed, Jul 30, 2014 at 10:18 AM, Jake Farrell <jfarrell@apache.org> wrote:

> 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