It's a very simple logger which can log your messages to a file or STDERR.
Changes for 0.4.1 - 2024-04-03T21:58:26Z
- Tidy
- List::Util dependency was removed
It's a very simple logger which can log your messages to a file or STDERR.
Changes for 0.4.0 - 2024-04-03T21:47:14Z
- STDOUT logger
- Time::Moment dependency was removed
Perl interface to the Argon2 key derivation functions
Changes for 0.021 - 2024-04-03T23:39:28+02:00
- Fix documentation of argon2_needs_rehash argument order
framework for easy creation of Enterprise Application Integration tasks
Changes for 1.913 - 2024-04-03T22:00:00Z
- execute hash not checked anymore, so it can be used to transport custom data; column definitions in DB.pm now debug level, tracing of data is now row wise (whole data structure was too big to be dumped)
A health check for your code
Changes for v1.9.1 - 2024-04-03T19:45:46Z
- Update README (Andrew Hewus Fresh)
- Pull request #13: Patch SM-4775 fixed typo bug and added test (Austin Hill)
- SM-4775 use default sort comparison (Austin Hill)
- SM-4775 fixed typo bug and added test (Austin Hill)
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]
