You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@vcl.apache.org by "ASF subversion and git services (JIRA)" <ji...@apache.org> on 2019/06/05 19:12:00 UTC

[jira] [Commented] (VCL-1121) Review all non-HTTPS dependency URLs

    [ https://issues.apache.org/jira/browse/VCL-1121?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16856957#comment-16856957 ] 

ASF subversion and git services commented on VCL-1121:
------------------------------------------------------

Commit c6ce604dfb81c5732a1e3dd37792efe2aa58ebdf in vcl's branch refs/heads/VCL-1121_install_perl_libs_cleanup from Josh Thompson
[ https://gitbox.apache.org/repos/asf?p=vcl.git;h=c6ce604 ]

VCL-1121 - Review all non-HTTPS dependency URLs

install_perl_libs.pl:
-added these to LINUX_PACKAGES so that an attempt to install them from yum will be attempted before getting them from CPAN:
  -perl-Frontier-RPC
  -perl-Frontier-RPC-Client
  -perl-LWP-Protocol-https
  -perl-Mo
  -perl-Object-InsideOut
  -perl-Scalar-List-Utils
  -perl-Expect
-modified installepel: changed mirrorlist URL from http:// to https://


> Review all non-HTTPS dependency URLs
> ------------------------------------
>
>                 Key: VCL-1121
>                 URL: https://issues.apache.org/jira/browse/VCL-1121
>             Project: VCL
>          Issue Type: Task
>          Components: database, vcld (backend), web gui (frontend)
>    Affects Versions: 2.5
>            Reporter: Andy Kurth
>            Priority: Major
>
> See the email sent by the Apache Security Team below.  We need to review all non-HTTPS URLs used in various places.
> One location I know has non-HTTPS URLs is *managementnode/bin/install_perl_libs.pl*.  It references an EPEL *_mirrorlist_* and a CPAN *_urllist_* by http.  I could imagine how these could be used in a MITM attack.  I'm not sure if an HTTPS alternative exists for these and don't know if these can be changed.  The email only says to "_fix them asap_", but gives no guidance for things that don't have an alternative.
> *install_perl_libs.pl* is only provided as an example.  We need to do an exhaustive check and are required to report back by May 31, 2019.
> {noformat}
> Created at: Tue, May 21, 2019 at 7:29 AM (Delivered after 53 seconds)
> From: Apache Security Team <[s...@apache.org>
> Subject: PRIORITY Action required: Security review for non-https dependency urls
> 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 security@apache.org by
> the 31st May 2019.
> The most common finding was HTTP references to repos like 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/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-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{noformat}
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)