2024-04-02T18:11:32 GwenDragon

Was mich so nervt, dass niemand weiß ob/wie Module einen Review bekommen, oder ob wir Programmierer:innen ohne Auditing-Erfahrungen einfach nur "treudoof" vertrauen sollten.

Perl ist da nicht anders als andere Software auch. Ich weiß nicht, von wem Du da einen Review erwartest, insbesondere für CPAN mit seinen tausenden von Karteileichen? Kennst oder verwendest Du CPAN::Audit?

Bei der Gelegenheit: In gut einer Woche (15.-17. März) findet in Frankfurt die Deutsche Perl/Raku-Konferenz statt. Einer der Vorträge hat den Titel "Die sichere "Lieferkette" CPAN". Renée Bäcker hält ziemlich regelmäßig Vorträge zu Security-Themen rund um Perl.

2024-04-02T18:11:32 GwenDragon

Ja, und wenn wir Glück haben patcht irgendjemand Lücken in Perl-Core, aber weniger in weiteren Modulen?

Da kann man sich zum Beispiel an die Debian-Security-Listen und deren Prozedere bei Security-Themen dranhängen: Perl spielt für Debian eine Rolle in der Bereitstellung der Distribution. Bei Modulen, die nicht als Pakete von Debian bereitgestellt werden, oder wenn man unbedingt die neueste Version zu brauchen meint, hilft das natürlich nichts.
Bei SUSE gibt's entsprechendes unter SUSE Security. Da empfiehlt sich mal ein Blick in deren Analyse der Lücke: Kein einziges Release war betroffen. Es hat nur Installationen aus dem "rolling release" im März 2024 erwischt (bei Debian entsprechend die "unstable"- und "testing"-Distribution im selben Zeitraum). Somit war das ganze zwar eine wichtige Lektion zum Thema "Supply Chain Security", aber kein weiteres Drama wert.

2024-04-02T18:11:32 GwenDragon

Und eine Mailingliste für Perl und Vulnerabilities oder ein spezielles Unterforum, gibt es das um dort mal was rein zu werfen!?

Dazu steht einiges in perlsecpolicy.

2024-04-02T18:11:32 GwenDragon

Es verbleibt das ungute Gefühl, dass Perls als absterbende Sprache zu wenig professionelle Beachtung wegen Vulnerabilities bekommt.

"Professionell" gibt's für Geld. Ich habe einige Jahre lang mein Gehalt genau dafür bekommen: Verfolgen der einschlägigen Security-Mailing-Listen, der Advisories der Anbieter, deren Software wir verbauen, selber testen und Tests auswerten... Zum Spaß hätte ich das nicht gemacht.

Ich möchte drauf hinweisen: Die liblzma-Lücke war keine Perl-Vulnerability. Das hat überhaupt nichts damit zu tun, ob Perl "absterbend" ist oder wer sich bei Perl um Sicherheits-Themen kümmert.