What exactly are we looking for? URLs to dependencies with http?
> On 21 May 2019, at 21:38, Denis Magda <dma...@gridgain.com> wrote: > > Yeap, > > This looks like a candidate for the change. > > Peter, Anton, is there a quick way to prepare a list of such dependencies > where "http" is to be replaced with "https"? > > -- > Denis Magda > > > On Tue, May 21, 2019 at 7:17 AM Ilya Kasnacheev <ilya.kasnach...@gmail.com > <mailto:ilya.kasnach...@gmail.com>> wrote: > Hello! > > I think we still have a http dependency on H2: > > <repository> > <releases> > <enabled>false</enabled> > </releases> > <snapshots> > <enabled>true</enabled> > <updatePolicy>always</updatePolicy> > <checksumPolicy>ignore</checksumPolicy> > </snapshots> > <id>h2database.com <http://h2database.com/></id> > <name>Snapshot repository on h2database.com > <http://h2database.com/></name> > <url>http://h2database.com/m2-repo > <http://h2database.com/m2-repo></url> > <layout>default</layout> > </repository> > > WDYT? > > Regards, > -- > Ilya Kasnacheev > > > вт, 21 мая 2019 г. в 17:08, Denis Magda <dma...@apache.org > <mailto:dma...@apache.org>>: > > > Igniters, > > > > Could anybody confirm we don’t have any issues with that? > > > > Denis > > > > ---------- Forwarded message ---------- > > From: *Apache Security Team* <secur...@apache.org > > <mailto:secur...@apache.org>> > > Date: Tuesday, May 21, 2019 > > Subject: PRIORITY Action required: Security review for non-https dependency > > urls > > To: Apache Security Team <secur...@apache.org <mailto:secur...@apache.org>> > > > > > > ASF Security received a report that a number of Apache projects have > > build dependencies downloaded using insecure urls. The reporter states > > this could be used in conjunction with a man-in-the-middle attack to > > compromise project builds. The reporter claims this a significant > > issue and will be making an announcement on June 10th and a number of > > press releases and industry reaction is expected. > > > > We have already contacted each of the projects the reporter detected. > > However we have not run any scanning ourselves to identify any other > > instances hence this email. > > > > We request that you review any build scripts and configurations for > > insecure urls where appropriate to your projects, fix them asap, and > > report back if you had to change anything to secur...@apache.org > > <mailto:secur...@apache.org> by > > the 31st May 2019. > > > > The most common finding was HTTP references to repos like maven.org > > <http://maven.org/> in > > build files (Gradle, Maven, SBT, or other tools). Here is an example > > showing repositories being used with http urls that should be changed > > to https: > > > > https://github.com/apache/flink/blob/d1542e9561c6235feb902c9c6d781b > > <https://github.com/apache/flink/blob/d1542e9561c6235feb902c9c6d781b> > > a416b8f784/pom.xml#L1017-L1038 > > <https://github.com/apache/flink/blob/d1542e9561c6235feb902c9c6d781ba416b8f784/pom.xml#L1017-L1038 > > > > <https://github.com/apache/flink/blob/d1542e9561c6235feb902c9c6d781ba416b8f784/pom.xml#L1017-L1038>> > > > > Note that searching for http:// might not be enough, look for http\:// > > too due to escaping. > > > > Although this issue is public on June 10th, please make fixes to > > insecure urls immediately. Also note that some repos will be moving > > to blocking http transfers in June and later: > > > > https://central.sonatype.org/articles/2019/Apr/30/http- > > <https://central.sonatype.org/articles/2019/Apr/30/http-> > > access-to-repo1mavenorg-and-repomavenapacheorg-is-being-deprecated/ > > > > The reporter claims that a full audit of affected projects is required > > to ensure builds were not made with tampered dependencies, and that > > CVE names should be given to each project, however we are not > > requiring this -- we believe it’s more likely a third party repo could > > be compromised with a malicious build than a MITM attack. If you > > disagree, let us know. Projects like Lucene do checksum whitelists of > > all their build dependencies, and you may wish to consider that as a > > protection against threats beyond just MITM. > > > > Best Regards, > > Mark J Cox > > VP, ASF Security Team > > > > > > > > -- > > - > > Denis > >
