FAQ
Hi!

I'll cut this reasonably short - we had two main threads of arguments
here, and they basically boil down to this:

    you) you shouldn't claim he claimed that, he didn't
    me) here's the quote, and he was asked multiple times to clarify, but didn't
    you) ah, but he didn't mean it
    me) well, again, he seems to disagree with you
    you) sorry that I am not up to your diligence level, I just pick out
         things and ignore the rest.

And:

    you) it seems the evidence you ask for is there
    me) except it isn't, this is just made up, no proof, no references
    you) but jenkins is referenced, and he is an authority
    me) maybe, but jenkins doesn't agree with perl, so he is evidence against
    you) perl is secure enough for me

Apart from the lameness of that last argument, it seems pretty obvious
that you either agree to my original statements, or ran out of arguments,
or both, as all you do is move the goalpost. I am not saying you do it
on purpose, but you are arguing unfairly and shift the discussion into
decidedly useless territory.

I really don't care if you can't read the whole thread, or if you feel
you have to ignore what others have said and take things out of context.
Neither do I really care whether things are secure enough for you or
not. These are strawmen that really aren't worth arguing against, and that
have nothing to do with the original argument.

Either just state that you agree, or state that you disagree but don't
have any arguments left. Do not shift the discussion into the area of your
personal failing or desires - this thread suffers most badly from being
swamped with personal issues, which dilutes the technical argument.

I will not continue these threads into this direction after this reply.
On Tue, Jun 17, 2014 at 07:00:33AM -0400, David Golden wrote:
Is that a fair restatement of your point of view?
No - I think I gave a succinct summary in my two recent replies
do demerphq, 20140615111330.ga4354@schmorp.de and especially
20140615114530.GB4354@schmorp.de.
I also want to apologize for seeming less diligent than you would
like. I don't have a photographic memory and these threads are now
probably at least a hundred pages long or more.
Can you explain how not having a photographic memory is causing or would
excuse you from simply dismissing arguments that prove you wrong?

I don't want your apologies, I simply want you to stop it and acknowledge
it when you have been shown wrong.
In anything that long, I tend not to focus on specific statements (such
as might pop up via search) and more on general trends. If someone says
"A" ten times and "B" once or twice, I tend to give the benefit of the
doubt that they probably meant "A" after all.
That is entirely your fault then, and you should fix that. When people say
"A" and "B", then picking "A" and claiming they didn't say "B" is wrong,
plain and simple.
I certainly didn't mean to waste your time trying to hunt down specific phrases.
Especially as hunting down those specific phrases just causes you to state
that those phrases are not what was meant, without any evidence, while
ignoring the evidence to the contrary.

If you don't accept facts as proof, then it's pointless to argue with you.
Disregarding evidence is the ultimate joker card, much like closing your
eyes and claiming you don't see anything.
ACM Queue had what I thought was an interesting article about trust:
http://queue.acm.org/detail.cfm?id=2630691
gives me a "site error", but is likely irrelevant for this discussion.
At least as far as Perl's hash function is concerned, for me, if an
attacker has to defeat a PRNG to gather the data to determine the
... which is absolutely trivial unless the PRNG is a CSPRNG. even the
world-best PRNGs (such as the mersenne twister) are absolutely trivial to
defeat.

It seems in much of the following, you make the mistake of assuming things
are difficult because you think they are difficult, even if they might be
trival in reality. This is a classical fallacy.

This is why actual evidence is so important - everybody can come up with
an algorithm they themselves cannot break, but most of those are trivially
breakable by others.
seed, then find a sufficiently large number of collisions to be
pathological,
... which can be done offline, and, worse, evidence exists that this seems
to be not that hard. it might even be trivial, since all that shields
us from a fatal break here is Yves word that it is somehow secure, even
though the only authority referenced also recommends the use of a vetted
algorithm that was made for this purpose, rather than cooking your own
hack.
and then send said collisions
... sending data is trivial. libwww perl even has had handy commandline
tools to do it for probably decades. it's hardly an obstacle.
to my app and must do all of that over a network
sending data over a network is a further obstacle?
and through an application that doesn't mitigate such things,
If applications mitigate those things, perl doesn't need to patch around
them.
assuming no monitoring to notice the traffic
that would entail,
Monitoring wouldn't catch this, the same way it didn't catch
heartbleed. Nothing about that traffic (content, volume) would be
suspicious to a monitoring program.
simply to overload a single Perl process on a
single machine, well, fine. I can live with that risk,
I actually can live with _that_ consequence too - so your argument
combined with mine boils down to "this attack which is likely trivial to
pull of and has no consequences I fear, which is why it's ok to break
documented behaviour relied upon by 100+ of the most-used modules on
CPAN".

Which doesn't quite make sense. Which is how this thread started.
tens of thousands of zombie machines. Someone who wants to bring my
application down can just DDOS me with traffic (as regularly happens
to various major internet sites roughly weekly it seems) with much
less effort than attacking my hashes.
Right, so why bother at all then?
In one of your posts (for which I won't be diligent and search,
sorry), you pointed out that complexity attacks are hard to fight and
that relying on other mechanisms like limits and monitoring are
essential. I agree with that completely.
So seem to be in violent agreement here: that whole security circus is
just circus - it doesn't actually fix the security bug, and even if,
it wouldn't be the right fix. It's really just obfuscation to pretend
something has been done, at the cost of an enourmous effort of fixing CPAN
to cope with the induced breakage. Again.

That was my original point that Yves so violently disagreed with, without
giving any evidence or explaining why.

Given that a real fix could have been had without that breakage and likely
with less overhead for normal use cases (the overhead would be detecting
the attack), this just shows how utterly braindead the solution really is.

--
                 The choice of a Deliantra, the free code+content MORPG
       -----==- _GNU_ http://www.deliantra.net
       ----==-- _ generation
       ---==---(_)__ __ ____ __ Marc Lehmann
       --==---/ / _ \/ // /\ \/ / schmorp@schmorp.de
       -=====/_/_//_/\_,_/ /_/\_\

Search Discussions

Discussion Posts

Previous

Follow ups

Related Discussions

People

Translate

site design / logo © 2021 Grokbase