#perl — Public Fediverse posts
Live and recent posts from across the Fediverse tagged #perl, aggregated by home.social.
-
I just discovered this great series of articles on the beauty of #Perl and its features: https://dev.to/damil/beautiful-perl-features-introduction-to-the-series-b6a
-
I just discovered this great series of articles on the beauty of #Perl and its features: https://dev.to/damil/beautiful-perl-features-introduction-to-the-series-b6a
-
I just discovered this great series of articles on the beauty of #Perl and its features: https://dev.to/damil/beautiful-perl-features-introduction-to-the-series-b6a
-
The Perl Toolchain Summit 2026: Security, Testing, Porting and Community Collaboration https://lobste.rs/s/ali1qx #perl
https://www.perl.com/article/perl-toolchain-summit-2026-key-results/ -
The Perl Toolchain Summit 2026: Security, Testing, Porting and Community Collaboration https://lobste.rs/s/ali1qx #perl
https://www.perl.com/article/perl-toolchain-summit-2026-key-results/ -
The Perl Toolchain Summit 2026: Security, Testing, Porting and Community Collaboration https://lobste.rs/s/ali1qx #perl
https://www.perl.com/article/perl-toolchain-summit-2026-key-results/ -
The Perl Toolchain Summit 2026: Security, Testing, Porting and Community Collaboration https://lobste.rs/s/ali1qx #perl
https://www.perl.com/article/perl-toolchain-summit-2026-key-results/ -
The Perl Toolchain Summit 2026: Security, Testing, Porting and Community Collaboration https://lobste.rs/s/ali1qx #perl
https://www.perl.com/article/perl-toolchain-summit-2026-key-results/ -
#Perl @PerlWChallenge 373 Equal List and List Division https://wlmb.github.io/2026/05/11/PWC373/
#noxp -
#Perl @PerlWChallenge 373 Equal List and List Division https://wlmb.github.io/2026/05/11/PWC373/
#noxp -
#Perl @PerlWChallenge 373 Equal List and List Division https://wlmb.github.io/2026/05/11/PWC373/
#noxp -
#Perl @PerlWChallenge 373 Equal List and List Division https://wlmb.github.io/2026/05/11/PWC373/
#noxp -
CW: Perl Weekly Challenge 373T2
#Perl @PerlWChallenge 373 Task 2: List Division
#noxp
```
perl -E '
for my($l,$n)(@ARGV){$s=(@L=split" ",$l)/$n; $r=@l%$n;say "$l, $n -> ",
$n>@L?-1:map{"(".join(" ",splice(@L,0,$s+($_<=$r))).")"}(1..$n)}
' "1 2 3 4 5" 2 "1 2 3 4 5 6" 3 "1 2 3" 2 "1 2 3 4 5 6 7 8 9 10" 5 \
"1 2 3" 4 "72 57 89 55 36 84 10 95 99 35" 7
``` -
CW: Perl Weekly Challenge 373T2
#Perl @PerlWChallenge 373 Task 2: List Division
#noxp
```
perl -E '
for my($l,$n)(@ARGV){$s=(@L=split" ",$l)/$n; $r=@l%$n;say "$l, $n -> ",
$n>@L?-1:map{"(".join(" ",splice(@L,0,$s+($_<=$r))).")"}(1..$n)}
' "1 2 3 4 5" 2 "1 2 3 4 5 6" 3 "1 2 3" 2 "1 2 3 4 5 6 7 8 9 10" 5 \
"1 2 3" 4 "72 57 89 55 36 84 10 95 99 35" 7
``` -
CW: Perl Weekly Challenge 373T2
#Perl @PerlWChallenge 373 Task 2: List Division
#noxp
```
perl -E '
for my($l,$n)(@ARGV){$s=(@L=split" ",$l)/$n; $r=@l%$n;say "$l, $n -> ",
$n>@L?-1:map{"(".join(" ",splice(@L,0,$s+($_<=$r))).")"}(1..$n)}
' "1 2 3 4 5" 2 "1 2 3 4 5 6" 3 "1 2 3" 2 "1 2 3 4 5 6 7 8 9 10" 5 \
"1 2 3" 4 "72 57 89 55 36 84 10 95 99 35" 7
``` -
CW: Perl Weekly Challenge 373T2
#Perl @PerlWChallenge 373 Task 2: List Division
#noxp
```
perl -E '
for my($l,$n)(@ARGV){$s=(@L=split" ",$l)/$n; $r=@l%$n;say "$l, $n -> ",
$n>@L?-1:map{"(".join(" ",splice(@L,0,$s+($_<=$r))).")"}(1..$n)}
' "1 2 3 4 5" 2 "1 2 3 4 5 6" 3 "1 2 3" 2 "1 2 3 4 5 6 7 8 9 10" 5 \
"1 2 3" 4 "72 57 89 55 36 84 10 95 99 35" 7
``` -
CW: Perl Weekly Challenge 373T2
#Perl @PerlWChallenge 373 Task 2: List Division
#noxp
```
perl -E '
for my($l,$n)(@ARGV){$s=(@L=split" ",$l)/$n; $r=@l%$n;say "$l, $n -> ",
$n>@L?-1:map{"(".join(" ",splice(@L,0,$s+($_<=$r))).")"}(1..$n)}
' "1 2 3 4 5" 2 "1 2 3 4 5 6" 3 "1 2 3" 2 "1 2 3 4 5 6 7 8 9 10" 5 \
"1 2 3" 4 "72 57 89 55 36 84 10 95 99 35" 7
``` -
CW: Perl Weekly Challenge 373T1
-
CW: Perl Weekly Challenge 373T1
-
CW: Perl Weekly Challenge 373T1
-
CW: Perl Weekly Challenge 373T1
-
CW: Perl Weekly Challenge 373T1
-
Perl Weekly Challenge 373's tasks are "Equal List" and "List Division". Because your kiss, your kiss is an equal list Because your kiss, your kiss divides my list Because your kiss is on my list of the best things in life #PerlWeeklyChallenge #raku #perl #python #elixir packy.dardan.com/b/pU
Perl Weekly Challenge: Because... -
Perl Weekly Challenge 373's tasks are "Equal List" and "List Division". Because your kiss, your kiss is an equal list Because your kiss, your kiss divides my list Because your kiss is on my list of the best things in life #PerlWeeklyChallenge #raku #perl #python #elixir packy.dardan.com/b/pU
Perl Weekly Challenge: Because... -
Perl Weekly Challenge 373's tasks are "Equal List" and "List Division". Because your kiss, your kiss is an equal list Because your kiss, your kiss divides my list Because your kiss is on my list of the best things in life #PerlWeeklyChallenge #raku #perl #python #elixir packy.dardan.com/b/pU
Perl Weekly Challenge: Because... -
I've uploaded a prototype module for generating and parsing metadata about software #AI and automation policies, based on ideas from the #Perl Toolchain Summit in April.
The idea is to have machine-readavle information about how code is generated, what kind of automated contributions are handled are allowed, and what kind of automation the maintainers of a project use.
There's a draft spec at https://github.com/CPAN-Security/cpan-metadata-v3/blob/main/automation-policy.md but it's already out-of-sync with the Perl code.
Ideas and feedback would be appreciated.
https://metacpan.org/release/RRWO/Dist-AutomationPolicy-v0.1.0
-
I've uploaded a prototype module for generating and parsing metadata about software #AI and automation policies, based on ideas from the #Perl Toolchain Summit in April.
The idea is to have machine-readavle information about how code is generated, what kind of automated contributions are handled are allowed, and what kind of automation the maintainers of a project use.
There's a draft spec at https://github.com/CPAN-Security/cpan-metadata-v3/blob/main/automation-policy.md but it's already out-of-sync with the Perl code.
Ideas and feedback would be appreciated.
https://metacpan.org/release/RRWO/Dist-AutomationPolicy-v0.1.0
-
I've uploaded a prototype module for generating and parsing metadata about software #AI and automation policies, based on ideas from the #Perl Toolchain Summit in April.
The idea is to have machine-readavle information about how code is generated, what kind of automated contributions are handled are allowed, and what kind of automation the maintainers of a project use.
There's a draft spec at https://github.com/CPAN-Security/cpan-metadata-v3/blob/main/automation-policy.md but it's already out-of-sync with the Perl code.
Ideas and feedback would be appreciated.
https://metacpan.org/release/RRWO/Dist-AutomationPolicy-v0.1.0
-
I've uploaded a prototype module for generating and parsing metadata about software #AI and automation policies, based on ideas from the #Perl Toolchain Summit in April.
The idea is to have machine-readavle information about how code is generated, what kind of automated contributions are handled are allowed, and what kind of automation the maintainers of a project use.
There's a draft spec at https://github.com/CPAN-Security/cpan-metadata-v3/blob/main/automation-policy.md but it's already out-of-sync with the Perl code.
Ideas and feedback would be appreciated.
https://metacpan.org/release/RRWO/Dist-AutomationPolicy-v0.1.0
-
I've uploaded a prototype module for generating and parsing metadata about software #AI and automation policies, based on ideas from the #Perl Toolchain Summit in April.
The idea is to have machine-readavle information about how code is generated, what kind of automated contributions are handled are allowed, and what kind of automation the maintainers of a project use.
There's a draft spec at https://github.com/CPAN-Security/cpan-metadata-v3/blob/main/automation-policy.md but it's already out-of-sync with the Perl code.
Ideas and feedback would be appreciated.
https://metacpan.org/release/RRWO/Dist-AutomationPolicy-v0.1.0
-
Boston PM Tech & Social on-line meeting tomorrow, Tues 7.30 EDT 🇺🇸 (=2330 GMT; soft start 7.00 pm for social and mic checks; JITSI not Zoom because FLOSS)
https://mobilizon.us/events/fd8f4dab-162b-4845-b382-f677ddda4452
-
Boston PM Tech & Social on-line meeting tomorrow, Tues 7.30 EDT 🇺🇸 (=2330 GMT; soft start 7.00 pm for social and mic checks; JITSI not Zoom because FLOSS)
https://mobilizon.us/events/fd8f4dab-162b-4845-b382-f677ddda4452
-
Boston PM Tech & Social on-line meeting tomorrow, Tues 7.30 EDT 🇺🇸 (=2330 GMT; soft start 7.00 pm for social and mic checks; JITSI not Zoom because FLOSS)
https://mobilizon.us/events/fd8f4dab-162b-4845-b382-f677ddda4452
-
Boston PM Tech & Social on-line meeting tomorrow, Tues 7.30 EDT 🇺🇸 (=2330 GMT; soft start 7.00 pm for social and mic checks; JITSI not Zoom because FLOSS)
https://mobilizon.us/events/fd8f4dab-162b-4845-b382-f677ddda4452
-
Boston PM Tech & Social on-line meeting tomorrow, Tues 7.30 EDT 🇺🇸 (=2330 GMT; soft start 7.00 pm for social and mic checks; JITSI not Zoom because FLOSS)
https://mobilizon.us/events/fd8f4dab-162b-4845-b382-f677ddda4452
-
Nope. Perl's built-in rand is seeded by 32-bits. The size of the internal state doesn't matter.
By making several requests to get session IDs, one can deduce the internal state of rand.
The multiplier does nothing to improve the security. Ultimately rand is just based in 32-bits.
-
Nope. Perl's built-in rand is seeded by 32-bits. The size of the internal state doesn't matter.
By making several requests to get session IDs, one can deduce the internal state of rand.
The multiplier does nothing to improve the security. Ultimately rand is just based in 32-bits.
-
Nope. Perl's built-in rand is seeded by 32-bits. The size of the internal state doesn't matter.
By making several requests to get session IDs, one can deduce the internal state of rand.
The multiplier does nothing to improve the security. Ultimately rand is just based in 32-bits.
-
Nope. Perl's built-in rand is seeded by 32-bits. The size of the internal state doesn't matter.
By making several requests to get session IDs, one can deduce the internal state of rand.
The multiplier does nothing to improve the security. Ultimately rand is just based in 32-bits.
-
Nope. Perl's built-in rand is seeded by 32-bits. The size of the internal state doesn't matter.
By making several requests to get session IDs, one can deduce the internal state of rand.
The multiplier does nothing to improve the security. Ultimately rand is just based in 32-bits.
-
@offseq Wow, the details are pretty wrong here.
The session ID generation relies on an MD5 hash seeded with the built-in rand() function, which is seeded with predictable 32-bit values derived from process ID, epoch time, and object reference address.
- Perl's built-in PRNG has a 48-bit internal state and is seeded with 48 bits, not 32 bits. Edit: See below. Perl internally seeds its PRNG with 32 bits from /dev/urandom.
- The code in WebDyne::Session does not seed the PRNG explicitly.
- The value passed to rand() is converted to a double-precision floating point value and acts as an upper bound on the generated number. It is not a seed.
- WebDyne::Session effectively generates this bound as
(process_id * 10_000_000_000.0 + unix_time()) * 10. The object address plays no part in this calculation. (It tries to, but the code is buggy and always multiplies by 10 instead.)
This predictability makes the session IDs insecure and potentially guessable by attackers, risking unauthorized access.
Yes. The generated session IDs are effectively something like
md5_hex("2.84319174058601e+16").The vulnerability affects versions through 2. 075 and does not apply to versions 1. 042 and earlier, which are distributed separately.
Incorrect. The vulnerability affects all versions of WebDyne::Session. The only difference is that in versions before 2.0, the "multiply by 10" code wasn't there, so the upper bound on generated random numbers was
process_id * 10_000_000_000.0 + unix_time(). Everything else (md5_hex(), rand(), etc) was exactly the same. -
@offseq Wow, the details are pretty wrong here.
The session ID generation relies on an MD5 hash seeded with the built-in rand() function, which is seeded with predictable 32-bit values derived from process ID, epoch time, and object reference address.
- Perl's built-in PRNG has a 48-bit internal state and is seeded with 48 bits, not 32 bits. Edit: See below. Perl internally seeds its PRNG with 32 bits from /dev/urandom.
- The code in WebDyne::Session does not seed the PRNG explicitly.
- The value passed to rand() is converted to a double-precision floating point value and acts as an upper bound on the generated number. It is not a seed.
- WebDyne::Session effectively generates this bound as
(process_id * 10_000_000_000.0 + unix_time()) * 10. The object address plays no part in this calculation. (It tries to, but the code is buggy and always multiplies by 10 instead.)
This predictability makes the session IDs insecure and potentially guessable by attackers, risking unauthorized access.
Yes. The generated session IDs are effectively something like
md5_hex("2.84319174058601e+16").The vulnerability affects versions through 2. 075 and does not apply to versions 1. 042 and earlier, which are distributed separately.
Incorrect. The vulnerability affects all versions of WebDyne::Session. The only difference is that in versions before 2.0, the "multiply by 10" code wasn't there, so the upper bound on generated random numbers was
process_id * 10_000_000_000.0 + unix_time(). Everything else (md5_hex(), rand(), etc) was exactly the same. -
@offseq Wow, the details are pretty wrong here.
The session ID generation relies on an MD5 hash seeded with the built-in rand() function, which is seeded with predictable 32-bit values derived from process ID, epoch time, and object reference address.
- Perl's built-in PRNG has a 48-bit internal state and is seeded with 48 bits, not 32 bits. Edit: See below. Perl internally seeds its PRNG with 32 bits from /dev/urandom.
- The code in WebDyne::Session does not seed the PRNG explicitly.
- The value passed to rand() is converted to a double-precision floating point value and acts as an upper bound on the generated number. It is not a seed.
- WebDyne::Session effectively generates this bound as
(process_id * 10_000_000_000.0 + unix_time()) * 10. The object address plays no part in this calculation. (It tries to, but the code is buggy and always multiplies by 10 instead.)
This predictability makes the session IDs insecure and potentially guessable by attackers, risking unauthorized access.
Yes. The generated session IDs are effectively something like
md5_hex("2.84319174058601e+16").The vulnerability affects versions through 2. 075 and does not apply to versions 1. 042 and earlier, which are distributed separately.
Incorrect. The vulnerability affects all versions of WebDyne::Session. The only difference is that in versions before 2.0, the "multiply by 10" code wasn't there, so the upper bound on generated random numbers was
process_id * 10_000_000_000.0 + unix_time(). Everything else (md5_hex(), rand(), etc) was exactly the same. -
@offseq Wow, the details are pretty wrong here.
The session ID generation relies on an MD5 hash seeded with the built-in rand() function, which is seeded with predictable 32-bit values derived from process ID, epoch time, and object reference address.
- Perl's built-in PRNG has a 48-bit internal state and is seeded with 48 bits, not 32 bits. Edit: See below. Perl internally seeds its PRNG with 32 bits from /dev/urandom.
- The code in WebDyne::Session does not seed the PRNG explicitly.
- The value passed to rand() is converted to a double-precision floating point value and acts as an upper bound on the generated number. It is not a seed.
- WebDyne::Session effectively generates this bound as
(process_id * 10_000_000_000.0 + unix_time()) * 10. The object address plays no part in this calculation. (It tries to, but the code is buggy and always multiplies by 10 instead.)
This predictability makes the session IDs insecure and potentially guessable by attackers, risking unauthorized access.
Yes. The generated session IDs are effectively something like
md5_hex("2.84319174058601e+16").The vulnerability affects versions through 2. 075 and does not apply to versions 1. 042 and earlier, which are distributed separately.
Incorrect. The vulnerability affects all versions of WebDyne::Session. The only difference is that in versions before 2.0, the "multiply by 10" code wasn't there, so the upper bound on generated random numbers was
process_id * 10_000_000_000.0 + unix_time(). Everything else (md5_hex(), rand(), etc) was exactly the same. -
@offseq Wow, the details are pretty wrong here.
The session ID generation relies on an MD5 hash seeded with the built-in rand() function, which is seeded with predictable 32-bit values derived from process ID, epoch time, and object reference address.
- Perl's built-in PRNG has a 48-bit internal state and is seeded with 48 bits, not 32 bits. Edit: See below. Perl internally seeds its PRNG with 32 bits from /dev/urandom.
- The code in WebDyne::Session does not seed the PRNG explicitly.
- The value passed to rand() is converted to a double-precision floating point value and acts as an upper bound on the generated number. It is not a seed.
- WebDyne::Session effectively generates this bound as
(process_id * 10_000_000_000.0 + unix_time()) * 10. The object address plays no part in this calculation. (It tries to, but the code is buggy and always multiplies by 10 instead.)
This predictability makes the session IDs insecure and potentially guessable by attackers, risking unauthorized access.
Yes. The generated session IDs are effectively something like
md5_hex("2.84319174058601e+16").The vulnerability affects versions through 2. 075 and does not apply to versions 1. 042 and earlier, which are distributed separately.
Incorrect. The vulnerability affects all versions of WebDyne::Session. The only difference is that in versions before 2.0, the "multiply by 10" code wasn't there, so the upper bound on generated random numbers was
process_id * 10_000_000_000.0 + unix_time(). Everything else (md5_hex(), rand(), etc) was exactly the same.
