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

# New Ticket Created by  yves orton 
# Please include the string:  [perl #117251]
# in the subject line of all future correspondence about this issue. 
# <URL: https://rt.perl.org:443/rt3/Ticket/Display.html?id=117251 >


On 21 March 2013 09:28, Marc Lehmann <schmorp@schmorp.de> wrote:
> On Thu, Mar 21, 2013 at 06:41:28AM +0100, Andreas Koenig <andreas.koenig.7os6VVqR@franz.ak.mind.de> 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.

Your opinion is noted. However given you appear to be uninformed as to
the details it is not worth much.

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

You are mistaken.

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

I am unaware of any such documentation. Please state your sources.

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

Yes, and this is a very tiny drop in a large bucket. If you think that
the changes I made are going to affect hash performance in any kind of
significant way then please provide evidence.

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

This doesn't make grammatical sense, so I don't know what you are trying to say.

> So please reconsider your choice of making perl worse again.

I don't think I have made Perl worse, so currently I have nothing to reconsider.

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

Thanks for your feedback.

I am sure the perl5porters who are regular contributors will give your
opinions on how they use their time the full attention and
consideration that they deserve.

Yves


-- 
perl -Mre=debug -e "/just|another|perl|hacker/"

• [perl #117251] Re: Bleadperl v5.17.9-200-g0e0ab62 breaks MLEHMANN/JSON-XS-2.33.tar.gz by yves orton