[
https://issues.apache.org/jira/browse/VCL-1121?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16845875#comment-16845875
]
Mike Jennings commented on VCL-1121:
------------------------------------
Andy,
I created a puppet installation script for the VCL Management node that
installs all perl libraries via OS Packages. Here is a list of the package
names that I used.
- perl-Archive-Tar
- perl-CPAN
- perl-Crypt-CBC
- perl-Crypt-OpenSSL-RSA
- perl-Crypt-Rijndael
- perl-DBD-MySQL
- perl-DBI
- perl-Digest-SHA1
- perl-IO-String
- perl-JSON
- perl-MailTools
- perl-Net-Jabber
- perl-Net-Netmask
- perl-RPC-XML
- perl-Text-CSV_XS
- perl-Time-HiRes
- perl-XML-Simple
- perl-YAML
- perl-Frontier-RPC
- perl-Frontier-RPC-Client
- perl-LWP-Protocol-https
- perl-Mo
- perl-Object-InsideOut
- perl-Scalar-List-Utils
- perl-Expect
I did run into a issue when going down this path as Net-SSH-Expect and
Net-Ping-External were not available as OS Packages in Centos 7. I did just
create my own Centos 7 rpms from the cpan sources files for these two OS
Libraries. I am not sure how we would want to handle these two edge cases.
Mike J
> 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 <[[email protected]>
> 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 [email protected] 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)
