This year, I was once again honored to be invited to the Perl Toolchain Summit (PTS), held in Vienna. Following productive years in Lisbon and Leipzig, the CPAN Security Group (CPANSec) spent time discussing how to improve the security of the Perl and CPAN ecosystem.
As always, the magic of PTS lies in the hallway discussions and focused groups where we can work on complex problems that are nearly impossible to coordinate over email or GitHub alone.
CPANSec: Maturing our CNA Role
Since we established CPANSec as a CVE Numbering Authority (CNA) in 2025, our focus has shifted toward efficiency and sustainability. We have a small group working on finding and documenting vulnerabilities. We spent time in Vienna discussing:
5.43.11 has so far turned up a few problems, thankfully small. As a result there are new versions of Archive::Tar and HTTP::Tiny to sync, which we intend to merge.
We decided how to proceed with our schedule: we will wait another week for any other findings in 5.43.11, and if nothing else shows up then we intend to start working on 5.44.0-RC0 at that point.
This post is adapted from my notes and recollection of the welcome
speech I gave on the morning of Thursday April 23, 2026, just before the
initial stand-up.
This post is brought to you by
Geizhals Preisvergleich,
a Gold sponsor for the Perl Toolchain Summit 2026.
You can learn more about Geizhals at the end of this article.
CPAN Testers produce a lot of data. Every CPAN distribution gets tested by our volunteers almost immediately after upload. These testers run every version of Perl across every platform you can imagine, and some you never knew existed. Instead of each project maintaining its own testing environments, the community maintains these systems so the project developers can focus on developing their project. There are more than 150 million test reports so far, and that number currently grows by about one million every month.
Sorting through all of those test reports is a big job. The community helps: Slaven Rezić, Andreas König, and others regularly submit tickets to a project's bug tracker for problems revealed by the testing systems they maintain. And individual maintainers can visit one of the UIs to view the data like the CPAN Testers Matrix (by Slaven) or CPAN Testers Magpie (by Scott Baker). But this, too, is a lot of manual effort.
This week we were back to full strength. We have now dealt with all of the belated issues and all of the blockers. Paul will be shipping 5.43.11 very shortly. With the amount of changes we have had to merge, we will not be able to rush the .11 cycle, but we intend to start the work on the 5.44 RC early, to ensure that we can release with as little additional delay as possible.
Well, not all of it ... yet. But some of it has been rewritten many times in many languages and "all" of it will be rewritten in many more languages. Of course "all" will never be reached, so it will be an ongoing endeavor, but at least you know the goalposts.
You can read it at https://perl.petamem.com/docs/eng/, and the language picker in the upper right hand corner will tell you, more honestly than any sentence in this post can, where the public-facing part of the work currently stands.
As already reported, I'm writing this color library. Recently I created my own test function for it. And since it was easier that I thought, I want to show you how, so you can write your own!
Paul is away this week so only Leon and Aristotle were present. A number of the belated-for-this-cycle issues have been addressed this week and we are following up on the remaining ones. We do not yet have a firm commitment for the release manager for 5.43.11.
Please share this post, the powers that be rage against us; you will not see any post regarding our activities in Perl Weekly!
Update: We got in Perl Weekly this week, but not for the right reasons. I hope in the future this will not be repeated or necessary. Thanks to the Perl Weekly editor who included this announcement. Special acknowledgement to David Cross for heading up the negotiations.
If you wish to comment about this post, please do so at r/perlcommunity.
Perl Community / Science Perl Committee Impact in 2025
Talks Delivered at Winter 2025 Perl Community Conference in Austin, TX
Video editing in progress, will be released after the 2026 Summer PPC.
It used to be so that a repository was only a place of work
and the distribution was the actual result of that work.
Only the contents of the distribution mattered. People would
read the files README and INSTALL from the distribution
after having downloaded it.
Not so anymore. Today the repository is out in the open in
GitHub,
GitLab,
Codeberg
or other shared hosting site.
On the other hand, the documentation in the distribution is often
discarded as distribution packages are rarely downloaded manually
but rather via a package manager which installs them automatically.
Publicly viewable repository has in fact become much more
than just a place of work. It is also an advertisement
for the project and of the community behind it, if there is
more than one author or contributor.
Use AI. Use it more and better. If you are not yet equipped to use it
well - that is fine, learning takes time - but please do not inhibit
those in the community who are.
That is the whole argument. The rest of this piece is why I think it
is correct, and why I think the current register of the Perl community
around this topic is costing us something specific and avoidable.
All three of us attended. We are dealing with a spate of (important, but thankfully relatively small) issues reported late in the cycle, so there will be a 5.43.11 dev release. We do not currently have a release manager for it yet and will ask for volunteers on the list.
This is a developer's perspective, not legal advice. I'm not a lawyer. What follows is my personal reading of publicly available licenses, policy documents, and one court decision. If you're making decisions about your module's legal exposure, talk to a lawyer.
The open source world is actively debating whether to accept AI-assisted contributions. QEMU, NetBSD, and Gentoo have said no. A lot of CPAN maintainers haven't written down a policy but have a reflex — if a PR looks AI-assisted, close it without a real review.
Two very different concerns sit underneath that reflex, and they usually get mashed together:
Quality. AI can produce plausible-looking code that doesn't actually work, hallucinates APIs, or subtly misunderstands the problem. This wastes reviewer time.
Copyright. AI might reproduce memorized training material the contributor has no right to relicense. The output itself may not even be copyrightable. The contributor may not actually own what they're submitting.
A while back, I received a pull request suggesting that I update the performance comparison with Encode.pm in my module, Unicode::UTF8. When I originally wrote Unicode::UTF8, Encode.pm used its own UTF-8 validation implementation. Since then, Karl Williamson has done extensive work improving Perl, and Encode.pm now relies on those validation routines based on Björn Höhrmann’s UTF-8 DFA decoder. It’s an elegant piece of code, widely adopted across many projects.
That said, I wasn’t particularly motivated to revisit the comparison, so I decided instead to look into faster scalar C implementations. While it has been suggested that Unicode::UTF8 should gain a SIMD implementation, and that may well be worthwhile, I wanted to first explore improvements to the scalar path, which would still be required as a fallback.
After some searching, I came across a tweet by Russ Cox showing performance numbers for a shift-based DFA implementation in Go, along with a link to a gist by Per Vognsen describing the technique.
All three of us attended further final release preparation. Issue triage continued; a number of small issues came in late, and we merged some of them. We also reverted a late small fix that we had merged recently which turned out to cause problems. Overall we once again left the meeting without open release blockers.
Two weeks ago we posted "PDL in Rust - A Native
Reimplementation of the Perl Data Language". At the time the
score was 45 tests, all green. That was enough to say "it compiles,
it runs, here is the arithmetic surface." It was not enough to say
"you can use this."
We are now on the second number. The current PDL implementation
in pperl covers roughly 3,000
assertions end-to-end: about 1,400 on the Perl-facing connector side
and about 1,600 on the engine side. As of this writing roughly 98%
of the connector assertions match upstream PDL 2.103 exactly, and
most of the remaining couple of dozen we already know why they
fail. By the time you read this the numbers will have drifted a
little in our favour - give or take - but the shape is the point,
not the decimal.
