Binary names with 5.16 With perl 5.16 added support for binary names, announcing it as support for unicode names. Unicode names were already supported since 5.8.4 with a negative length stored in the hash key of the symbol. Supporting binary names without any supporting measures opened huge security holes, as names are mapped 1:1 to filenames when searching for a package, and as we know the C API for files or names just ignores a \0, leading to inconsistencies.
cperl hash tables
The old perl5 hash table uses linked lists for its collisions, with slow out-of-cache pointer chasing and data overhead. unsorted flags at the end, while some flags are needed for compare. has questionable security measures to slow down all cases. seed ok, randomize iter maybe, but randomize the collisions and slow hash funcs is stupid. The security should be fixed with proper collision iteration, not by pseudo-security theatre upfront.
Worst perl5 bugs
A small list of the worst perl5 bugs, all fixed in cperl DoS It’s trivial to DoS a perl5 system. $a[9223372036854]=0; %a=(0..4294967296); Examples for a 64bit system, but also trivial on 32bit. It creates a huge array or hash, which runs out of memory in the VMM subsystem which eventually kills the process. cperl dies with “Too many elements”, here even at compile-time. No Hash Security Nothing is done against the root-cause of a hash flood denial of service attack with colliding keys, only some security theatre by using slower hash functions and slower collision resolution KEY_PERTURB_RANDOM.
p5p incompetence
So I was continously asked to explain why I call p5p too incompetent to design anything for the perl5 language and any internal VM features. So far I was reluctant to do so, because users will be as emberrassed as I am, and need a way to got forward. Now that I can offer a way forward it might be easier to publish the detailed criticsm on p5p’s incompetence. From a high level view it’s pretty easy to prove.
The dangerous SipHash myth
SipHash claims that its “cryptographically strong pseudo random function” properties protects against hash table DoS flood attacks. This is wrong, because for a successful attack against a SipHash hash table with chained linked lists or linear probing it is enough to get the secret random seed, and then brute force create collisions, which is doable in <1s for 16k keys, 2m for 16k keys, and from 32k to 268M keys in 4 minutes.
cperl is not a religion
The recent perl5 management problems are disturbing Criticizing the broken perl5 development process, the managers and esp. various technical problems is suddenly explicitly disallowed in the various perl5 forums by citing a new “bad faith” code of conduct rule. Mentioning incompetence of submitters is considered uncivil, and mentioning the marketing lies of the previous “pumpkin” (admin) is also considered uncivil. But lying, abusing the powers, and constant usage and even encouragement of foul language is interestingly not considered uncivil.