develooper Front page | perl.perl5.porters | Postings from March 2013

[perl #117243] Re: Bleadperl v5.17.9-200-g0e0ab62 breaks MLEHMANN/JSON-XS-2.33.tar.gz

Thread Next
schmorp @ schmorp . de
March 21, 2013 13:27
[perl #117243] Re: Bleadperl v5.17.9-200-g0e0ab62 breaks MLEHMANN/JSON-XS-2.33.tar.gz
Message ID:
# New Ticket Created by 
# Please include the string:  [perl #117243]
# in the subject line of all future correspondence about this issue. 
# <URL: >

On Thu, Mar 21, 2013 at 06:41:28AM +0100, Andreas Koenig <> wrote:
>     Harden hashes against hash seed discovery by randomizing hash iteration

Thanks andreas for pointing this out, hi Yves.

I am talking a bit out of my ass here (call it a rant if you wish), and
can only guess whats going on. But in short: this change is wrong.

- Unless I am mistaken, this is to avoid a DOS attack. DOS attacks are easy
  to protect against, and this won't protect me against basically any form
  of attack, so it's useless. Far better methods exist that prevent every
  form of memory resource and/or cpu time starvation.
- I'd say this simply breaks perl, as perl documented the order is fixed,
  at least between runs (I would argue even the earlier fix to randomise
  between runs is a bug). Sure, the wording is ambiguous, but that doesn't
  make it any better.
- Perl hash already are very slow (just write yourself some XS functions to
  interface to gcc's unordered_hash and watch the speed - despite the
  overhead of XS).
- Taking out the inability to write a proper hash on all the perl developers
  out there is just wrong - Perl is the runtime, and should get it right,
  if possible.

So please reconsider your choice of making perl worse again.

On a tangent, the current regime of perl development - making perl worse,
breaking CPAN more and more, adding lots of incompatible changes while at
the same time requiring use feature is in the wrong for quite some time
now, and, frankly, the only reason I don't fork perl is simply that I
am not prepared to maintain yet another software package. Breaking CPAN
packages every 6 months just doesn't cut it for me, and creates way too
much needless work on my side. Not even mentioning the train wrecks of
design hoisted on us in recent releases (smart matches, given/when being
lexical when everything else is dynamical in perl, mandatory use strict
backfitted, yet more version string madness etc. etc. - I know designing
these things is not easy, but if it's hard, don't make hacks and release
them every few months. OR, hey, even the regex changes which look nice,
but I have yet to see something that is either faster or more readable
when using them to implement something in the real world).

I'd much prefer if the current perl5porters would go back to maintaining
perl _5_ properly and taking out their dreams on breaking perl and making
it "better" on Perl 6.

But hey, for what I know I am probably in the minority and other people
embrace this, but I am certainly not alone in these sentiments.

So again, please reconsider, and think about either writing a proper
hash that doesn't suffer from simple attacks (a bit more speed would be
appreciated as well), or forget about making ineffective partial fixes for
problems that make writing perl harder, and fix nothing.

Yves, I know you are not to blame, at least not alone, but it's really
getting too much for me as a user of perl. I honestly wish back the lazy
days of perl 5.8, which had many bugs, was broken a lot, but at least
respected Perl as a language and CPAN for its code, instead of treating
both as slightly broken anyways.

                The choice of a       Deliantra, the free code+content MORPG
      -----==-     _GNU_    
      ----==-- _       generation
      ---==---(_)__  __ ____  __      Marc Lehmann
      --==---/ / _ \/ // /\ \/ /
      -=====/_/_//_/\_,_/ /_/\_\

Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About