various utility functions
Changes for 0.101 - 2024-04-04
- Work around a warning in the development version of perl (thanks, Shlomi Fish). [RT#152677]
Greetings monks, question about reorganizing a Perl module, and if the following is a good approach:
The module is 7300 lines in one file and has 106 subs. I'll call it Cat.pm, its mostly called as an object like Cat->new(); but could be called like Cat->black() or Cat::Black::meow
To simplify maintaining this file I am thinking I can make a new sub directory in the same folder as the file call it Cat/ and move the 105 of the 106 subs to about 12 or 15 new .pm's in the new folder.
I plan later to rewrite one or more of those as XS modules. Cat/Tabby_XS.pm etc.
Then in Cat.pm I would just have use Cat::Black; use Cat::White; use Cat:;tabby; ...etc in Cat.pm
The only sub I'd keep in Cat.pm is sub new which looks like this:
sub new { #Object Interface #http://www.perl.com/pub/1999/09/refererents.html my $type = shift; my $self = {}; $self->{dbh} = shift; bless $self, $type; $self; } I have a book on cleaning up old perl code but it is now a very old book LOL, will moving the subroutines to new files break old code that depends on Cat.pm? TIA
submitted by /u/bug_splat
[link] [comments]
This isn't directly perl-related, but it's a good reminder that as the bus-factor of our projects dwindle down to 0, the danger of a dependency attack goes up.
The story is still unfolding, and I've just been reading it from the HN post
In this case, it appears that the maintainer of xz-utils, who has been maintaining it since 2009 and mentioned online that they don't really have the capacity for it anymore finally had a motivated helper show up to assist with the work 2.5 years ago. That motivated helper now appears to either be a long-con state actor, or a compromised account.
liblzma is used by libsystemd. Redhat and Debian patch ssh to use libsystemd. The startup code of libxz detects when it is loaded into sshd during initialization and replaces a core auth function of sshd with its own copy. The malicious code comes from compressed compiled code within one of the libxz unit test files that gets sneakily injected into the build during the ./configure script. The person who discovered it only found it due to valgrind errors and a slower startup time for ssh, which are mistakes a more sophisticated attacker might not have made.
Oh, and of course the question on everyone's mind, you're probably not affected yet because the latest liblzma is only used in pre-release distros right now. But check if you have xz 5.6 or later. However, the author has been contributing to xz for 2.5 years so who knows if this is the first attack or not...
submitted by /u/nrdvana
[link] [comments]
