[
https://issues.apache.org/jira/browse/VCL-1121?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16852318#comment-16852318
]
Josh Thompson commented on VCL-1121:
------------------------------------
{quote}In the install_perl_libs.pl the code is generating a defuult MyConfig.pm
file for use with cpan.
If we change the url list from
"urllist" => [q[http://cpan-rsync.perl.org/]],
to
'urllist' => [q[https://cpan.metacpan.org/],
q[https://mirrors.namecheap.com/CPAN/],
q[https://mirrors.syringanetworks.net/CPAN/], q[https://ftp.wayne.edu/CPAN/]],
Then the cpan installs will use https uri's to get the source code and build
the modules locally.
{quote}
This sounds like a workable solution to me.
Mike - Can you go ahead and update install_perl_libs.pl on the
VCL-1121_install_perl_libs_cleanup branch to use the urllist you've suggested?
-Josh
> 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 <[secur...@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 secur...@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)
