Timothy Legge

This year I was invited to the PTS conference in Lisbon as part of the CPAN Security group. Together we have been working on ways to improve the security of the Perl ecosystem. This was a great chance for members of the CPANSec group to meet in person, get to know each other better and discuss some of the items we have been working on lately. Welcome to Nicolas our newest member.

Cyber Resilience Act
One of the major items in the security world is related to the changes coming to Europe as part of the Cyber Resilience Act (CRA). Salve gave a presentation on the updates to the CRA from the past year. The last 12 months has given us a much clearer view of how it affects Open Source projects like Perl and CPAN developers. Open Source developers are less impacted than feared, but if we want our projects to be used it will be important for us to understand what downstream projects and commercial companies will need in order to make use of the tools we make.

Perl and CPAN Modules "need" CVEs
Over the last few months Stig and I have been working through requesting and updating CVE numbers for existing, but older and mostly fixed, vulnerabilities in CPAN modules. During the Summit we presented on this work and the reasons it is important for all vulnerabilities to get published CVEs (whether they are newly discovered issues or issues resolved several years ago).

Our work on this has already shown results. In particular, we have seen that downstream projects (particularly Linux distributions) monitor for CVEs and take note. While CPAN modules often list vulnerability fixes in the Changelog, and CPAN::Audit provides a list of all known vulnerabilities, it is the CVE database that is monitored.

In several cases, it was only after the CVE was published, that a distribution downloaded and released a patched version. Even though that patched module had been released to CPAN months or even years before it was the CVE that got action.

CVE Numbering Authority (CNA)
Stig and I have been researching whether a Perl specific CNA should be established and reviewing the prior work done by the Linux Kernel and Python communities to establish their CNAs.

A Perl specific CNA can be granted the scope for which allows it to grant CVE numbers and publish CVEs. A Perl specific CNA would have more control over the CVEs, which allows it to provide more complete and more accurate information in published CVEs. In addition, because it is (hopefully) working on a smaller number of requests, the CNA can respond quicker.

A number of us met with the Perl Steering Council to discuss whether to set up a CNA and if so what scope should be requested. It was felt that there were good reasons to have a Perl CNA and that it should have scope for both the Perl Interpreter (Perl Core), and CPAN published modules. We will continue to work toward setting up a CNA. There is some upfront work required and we will be determining the expected long term effort. As we go forward we will likely need some assistance, so if you are familiar with or interested in the process, and being a part of it, please reach out.

Linux distributions and CPAN Modules

A few of us met to discuss the state of CPAN modules in Linux distributions. We talked about how the distributions package modules and their approach to patches. The group had representation from Suse, Fedora, Alpinelinux and NixOS. Each distribution faces similar issues:

1. Resolving dependencies (especially for non CPAN dependencies)


2. Applying patches for module issues


3. Vulnerability notifications

Tina has worked on a Suse script for package build files and I have worked on Alpinelinux's script for generating package build files. There is a lot of overlap in these scripts and in the scripts/processes used by other distributions. A CPAN module to perform that processing would be helpful. As distributions will likely need to meet the requirements of the CRA, including a Software Bill of Materials (SBOM), helping them meet their existing packaging needs today will help them generate SBOMs in the future.

Patches for vulnerabilities (or functionality) are an ongoing issue for distributions. Each distribution maintains a set of patches for some of their packaged CPAN modules. Patches could be related to packaging, failing tests, functionality improvements or vulnerability fixes. In many cases the patches are available on Request Tracker or Github but have not been implemented in a released version. While some distributions may use the same patch there may also be differences. There was some discussion of how to get these patches into an upstream CPAN release and whether a centralized patch repository of vetted patches makes sense.

The discussion of vulnerability notifications did tend to agree that the CVE database is the usual source of vulnerability notification. If there is no CVE the issue may be missed entirely.

Secure by Default
Secure by default is becoming more of a necessity. Too many times people have been compromised via issues that are the result of insecure configurations. The options are often there, but require the user to specifically make the secure choice.

This is often done to ensure backward compatibility and while it is a good goal it is not generally compatible with secure configurations. Sometimes the responsible decision is to break backward compatibility.

One of the big items worked on by a couple of the CPAN Security members (Nicolas, Breno and Stig) was a patch to make cpanm "Secure by Default" by requiring HTTPS connections only. As this might break some CI pipelines and smokers, etc. Miyagawa is giving it some thought. Hopefully though the PR, or a modified version, will get accepted soon. Feel free to comment on the pull request to show your support (or concerns).

Crypt::OpenSSL::PKCS12
Before PTS Tux had reached out about some changes I had submitted for the module. During PTS, Tux asked whether some improvements could be made to provide information output similar to that outputted by openssl's info command. I took a look at the module and created a patch to provide the information that Tux required. Now that I am back from PTS I need to get that patch ready for submission to the git repo as a PR.

Crypt::OpenSSL::RSA and OpenSSL 3+
The time away from work and other responsibilities (as well as a 7 hour plane ride home) allowed me to work on something I have been planning to look at for quite awhile. Namely creating a patch for Crypt::OpenSSL::RSA to use the updated API calls for OpenSSL 3+ instead of the deprecated functions of older versions.

Anyone who has ever looked at an OpenSSL based XS module and the OpenSSL api in general would likely agree that you need to be in the correct frame of mind, with lots of time to dedicate to it to make progress. I was however, able to submit a draft pull request that updates the API to use non-deprecated functions and get clean builds on Linux, MacOS, Windows, MSSYS and CYGWIN. Todd has said that he will review it soon. My only remaining work (unless changes are needed) is to produce some encrypted data tests to verify the before and after and some performance tests to compare the before and after impacts of using the new API calls.

Organizers
Laurent Boivin, Philippe Bruhat and Breno de Oliveira, Neil Bowers, Barbara Veloso and Teresa Tavares did a fabulous job. From my point of view everything went without a hitch, well planned, well executed. Given that neither of them were in Portugal and Breno did the Lisbon arrangements from Brazil that is amazing and speaks to their abilities to organize. Fantastic work from all involved.

PTS and sponsors
Having been to my first PTS there is no doubt of the importance of the summit and the importance of the sponsors to making it a success. A big shout out to sponsors that contributed to the success of the summit.

Monetary sponsors:
Booking.com, The Perl and Raku Foundation, Deriv, cPanel, Inc, Japan Perl Association, Perl-Services, Simplelists Ltd, Ctrl O Ltd, Findus Internet-OPAC, Harald Joerg, Steven Schubiger.

In kind sponsors:
Fastmail, Grant Street Group, Deft, Procura, Healex GmbH, SUSE, Zoopla.