#cpan — Public Fediverse posts

New Sticker onboard.

#Underbar #Perl #CPAN

New Sticker onboard.

#Underbar #Perl #CPAN

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

#CPAN

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

#CPAN

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

#CPAN

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

#CPAN

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

#CPAN

@barubary @offseq

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.

#perl #cpan #cve

@barubary @offseq

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.

#perl #cpan #cve

@barubary @offseq

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.

#perl #cpan #cve

@barubary @offseq

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.

#perl #cpan #cve

@barubary @offseq

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.

#perl #cpan #cve

@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.

#perl #CPAN #cve

@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.

#perl #CPAN #cve

@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.

#perl #CPAN #cve

@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.

#perl #CPAN #cve

@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.

#perl #CPAN #cve

@manwar Test2 is great, but whenever I see something using yath on one of my #CPAN testing machines it seems to be incredibly slow. Don't know why, and have better things to do than investigate, but that's put me off using it.

@manwar Test2 is great, but whenever I see something using yath on one of my #CPAN testing machines it seems to be incredibly slow. Don't know why, and have better things to do than investigate, but that's put me off using it.

@manwar Test2 is great, but whenever I see something using yath on one of my #CPAN testing machines it seems to be incredibly slow. Don't know why, and have better things to do than investigate, but that's put me off using it.

@manwar Test2 is great, but whenever I see something using yath on one of my #CPAN testing machines it seems to be incredibly slow. Don't know why, and have better things to do than investigate, but that's put me off using it.

@manwar Test2 is great, but whenever I see something using yath on one of my #CPAN testing machines it seems to be incredibly slow. Don't know why, and have better things to do than investigate, but that's put me off using it.

"575 Pull Requests in Three Weeks: What Happens When #AI Meets #CPAN Maintenance"

This is an interesting read, including the comments.

https://blogs.perl.org/users/todd_rinaldo/2026/04/575-pull-requests-in-three-weeks-what-happens-when-ai-meets-cpan-maintenance.html

#Perl #LLM #Claude

"575 Pull Requests in Three Weeks: What Happens When #AI Meets #CPAN Maintenance"

This is an interesting read, including the comments.

https://blogs.perl.org/users/todd_rinaldo/2026/04/575-pull-requests-in-three-weeks-what-happens-when-ai-meets-cpan-maintenance.html

#Perl #LLM #Claude

"575 Pull Requests in Three Weeks: What Happens When #AI Meets #CPAN Maintenance"

This is an interesting read, including the comments.

https://blogs.perl.org/users/todd_rinaldo/2026/04/575-pull-requests-in-three-weeks-what-happens-when-ai-meets-cpan-maintenance.html

#Perl #LLM #Claude

"575 Pull Requests in Three Weeks: What Happens When #AI Meets #CPAN Maintenance"

This is an interesting read, including the comments.

https://blogs.perl.org/users/todd_rinaldo/2026/04/575-pull-requests-in-three-weeks-what-happens-when-ai-meets-cpan-maintenance.html

#Perl #LLM #Claude

"575 Pull Requests in Three Weeks: What Happens When #AI Meets #CPAN Maintenance"

This is an interesting read, including the comments.

https://blogs.perl.org/users/todd_rinaldo/2026/04/575-pull-requests-in-three-weeks-what-happens-when-ai-meets-cpan-maintenance.html

#Perl #LLM #Claude

I've uploaded a new #Perl Critic policy that checks code for naive random data generation from a hash over not-so-randonm sources like rand(), system time, pid such as

md5_hex( rand . time . $$ . ++$counter )

This anti-pattern is used in many places, and has been the reason for several CVEs.

https://metacpan.org/release/RRWO/Perl-Critic-Policy-Security-RandBytesFromHash-v0.1.0

#CPAN #security

As a scholarly aside, I am curious as to who first came up this anti-pattern.

I've uploaded a new #Perl Critic policy that checks code for naive random data generation from a hash over not-so-randonm sources like rand(), system time, pid such as

md5_hex( rand . time . $$ . ++$counter )

This anti-pattern is used in many places, and has been the reason for several CVEs.

https://metacpan.org/release/RRWO/Perl-Critic-Policy-Security-RandBytesFromHash-v0.1.0

#CPAN #security

As a scholarly aside, I am curious as to who first came up this anti-pattern.

I've uploaded a new #Perl Critic policy that checks code for naive random data generation from a hash over not-so-randonm sources like rand(), system time, pid such as

md5_hex( rand . time . $$ . ++$counter )

This anti-pattern is used in many places, and has been the reason for several CVEs.

https://metacpan.org/release/RRWO/Perl-Critic-Policy-Security-RandBytesFromHash-v0.1.0

#CPAN #security

As a scholarly aside, I am curious as to who first came up this anti-pattern.

I've uploaded a new #Perl Critic policy that checks code for naive random data generation from a hash over not-so-randonm sources like rand(), system time, pid such as

md5_hex( rand . time . $$ . ++$counter )

This anti-pattern is used in many places, and has been the reason for several CVEs.

https://metacpan.org/release/RRWO/Perl-Critic-Policy-Security-RandBytesFromHash-v0.1.0

#CPAN #security

As a scholarly aside, I am curious as to who first came up this anti-pattern.

I've uploaded a new #Perl Critic policy that checks code for naive random data generation from a hash over not-so-randonm sources like rand(), system time, pid such as

md5_hex( rand . time . $$ . ++$counter )

This anti-pattern is used in many places, and has been the reason for several CVEs.

https://metacpan.org/release/RRWO/Perl-Critic-Policy-Security-RandBytesFromHash-v0.1.0

#CPAN #security

As a scholarly aside, I am curious as to who first came up this anti-pattern.

Gonna build a #CPAN testing VM with #DragonflyBSD. Any gotchas that my fedihomies think that a seasoned Unixhead should know about?

#perl

Gonna build a #CPAN testing VM with #DragonflyBSD. Any gotchas that my fedihomies think that a seasoned Unixhead should know about?

#perl

Gonna build a #CPAN testing VM with #DragonflyBSD. Any gotchas that my fedihomies think that a seasoned Unixhead should know about?

#perl

Gonna build a #CPAN testing VM with #DragonflyBSD. Any gotchas that my fedihomies think that a seasoned Unixhead should know about?

#perl

Gonna build a #CPAN testing VM with #DragonflyBSD. Any gotchas that my fedihomies think that a seasoned Unixhead should know about?

#perl

A few days ago I tried to build some perls with 32 bit ints and 128 bit floats. Cue test failures. Today I tried again, and this time I read my notes from last time on how to do it, and it Just Works.

Yay past me!

(the #BigInt modules bundled with some versions of perl don't like that combination of data sizes; the solution is to ignore their test failures, install anyway, and then upgrade to the latest versions from the #CPAN)

#perl #32bit #RidiculousComputing #ComputationalPerversions

A few days ago I tried to build some perls with 32 bit ints and 128 bit floats. Cue test failures. Today I tried again, and this time I read my notes from last time on how to do it, and it Just Works.

Yay past me!

(the #BigInt modules bundled with some versions of perl don't like that combination of data sizes; the solution is to ignore their test failures, install anyway, and then upgrade to the latest versions from the #CPAN)

#perl #32bit #RidiculousComputing #ComputationalPerversions

A few days ago I tried to build some perls with 32 bit ints and 128 bit floats. Cue test failures. Today I tried again, and this time I read my notes from last time on how to do it, and it Just Works.

Yay past me!

(the #BigInt modules bundled with some versions of perl don't like that combination of data sizes; the solution is to ignore their test failures, install anyway, and then upgrade to the latest versions from the #CPAN)

#perl #32bit #RidiculousComputing #ComputationalPerversions

A few days ago I tried to build some perls with 32 bit ints and 128 bit floats. Cue test failures. Today I tried again, and this time I read my notes from last time on how to do it, and it Just Works.

Yay past me!

(the #BigInt modules bundled with some versions of perl don't like that combination of data sizes; the solution is to ignore their test failures, install anyway, and then upgrade to the latest versions from the #CPAN)

#perl #32bit #RidiculousComputing #ComputationalPerversions

A few days ago I tried to build some perls with 32 bit ints and 128 bit floats. Cue test failures. Today I tried again, and this time I read my notes from last time on how to do it, and it Just Works.

Yay past me!

(the #BigInt modules bundled with some versions of perl don't like that combination of data sizes; the solution is to ignore their test failures, install anyway, and then upgrade to the latest versions from the #CPAN)

#perl #32bit #RidiculousComputing #ComputationalPerversions

I have released a new version of App::CpanDak, my sub-class of App::cpanminus / cpanm with "some sort of distroprefs"

You could already apply patches, skip tests, and set environment variables, to any distribution you installed; now you can augment version specifications.

Some::Fancy::Library has released a new version 1.3.4 that doesn't install cleanly? add a Some-Fancy-Library.options.yml with:

---
add_version_spec: "!= 1.3.4"

I have released a new version of App::CpanDak, my sub-class of App::cpanminus / cpanm with "some sort of distroprefs"

You could already apply patches, skip tests, and set environment variables, to any distribution you installed; now you can augment version specifications.

Some::Fancy::Library has released a new version 1.3.4 that doesn't install cleanly? add a Some-Fancy-Library.options.yml with:

---
add_version_spec: "!= 1.3.4"

I have released a new version of App::CpanDak, my sub-class of App::cpanminus / cpanm with "some sort of distroprefs"

You could already apply patches, skip tests, and set environment variables, to any distribution you installed; now you can augment version specifications.

Some::Fancy::Library has released a new version 1.3.4 that doesn't install cleanly? add a Some-Fancy-Library.options.yml with:

---
add_version_spec: "!= 1.3.4"

I have released a new version of App::CpanDak, my sub-class of App::cpanminus / cpanm with "some sort of distroprefs"

You could already apply patches, skip tests, and set environment variables, to any distribution you installed; now you can augment version specifications.

Some::Fancy::Library has released a new version 1.3.4 that doesn't install cleanly? add a Some-Fancy-Library.options.yml with:

---
add_version_spec: "!= 1.3.4"

I have released a new version of App::CpanDak, my sub-class of App::cpanminus / cpanm with "some sort of distroprefs"

You could already apply patches, skip tests, and set environment variables, to any distribution you installed; now you can augment version specifications.

Some::Fancy::Library has released a new version 1.3.4 that doesn't install cleanly? add a Some-Fancy-Library.options.yml with:

---
add_version_spec: "!= 1.3.4"

Hm, did Data::Random got deleted from #CPAN? I have some failing build pipelines and metacpan does not list it anymore, only some dependencies. #Perl Anybody knows who can investigate this?

Hm, did Data::Random got deleted from #CPAN? I have some failing build pipelines and metacpan does not list it anymore, only some dependencies. #Perl Anybody knows who can investigate this?

Hm, did Data::Random got deleted from #CPAN? I have some failing build pipelines and metacpan does not list it anymore, only some dependencies. #Perl Anybody knows who can investigate this?