This week in PSC (106) | 2023-05-05
Porters,
After a meeting around an actual physical table at the Perl Toolchain Summit last week, the three of us were back to our regular video calls. The call was longer than usual, as we delved into the code of CPAN.pm.
Release blockers for 5.038
We looked at the tickets we tagged “Release Blocker” last week, and made some decisions.
The following issues are NOT release blockers: - Path-Class (https://github.com/Perl/perl5/issues/20039): it’s been broken for the past 2 stable releases - App-ClusterSSH (https://github.com/Perl/perl5/issues/20376): already failing in 5.036, added comments in the ticket - XS-Parse-Keyword, Devel-Chitin, others (https://github.com/Perl/perl5/issues/20384): we should add a note to perldelta explaining the breaking change - Number-Format (https://github.com/Perl/perl5/issues/20571): it should be adopted to make a new release - Text-MicroMason (https://github.com/Perl/perl5/issues/21037): the tests depend on the exact error message (this is too fragile)
This last one is definitely a release blocker: - XML-PathScript (https://github.com/Perl/perl5/issues/21044): Rik will send an email to the list
Installing modules securily with Perl default install
As much as we want HTTPS support in core, we can’t have it for v5.38. However, we want a newly installed Perl + CPAN.pm to be secure by default. Currently this is not the case because HTTP::Tiny does not use SSL normally, and even when installed it does not set verify_SSL to true.
HTTP::Tiny should be secure by default (set verify_SSL to true, complain if there are no root CAs available).
CPAN.pm is a far more complex question because its code is a deep twisty maze of years of piled-up workarounds and legacy code (FTP by default?), and the question of “what should this do?” is far less clear-cut. More discussions will have to be had with more people who are deeper involved, to work out what would be best.
We should do this ASAP, as it is a release blocker.
Please be cautious with phrases like "Installing modules securily". I believe that the goal is to be able to copy the tarball files via https. So whilst this is a very necessary step towards whatever "securily" is, it's not the destination.
"Secure" installation would also involve a signature authority, signing the cpan modules, some verification of the author when the module is published, and checking all of these at install time.
Probably other things too.