From: Philippe Veber <philippe.veber@gmail.com>
To: Paolo Donadeo <p.donadeo@gmail.com>
Cc: OCaml mailing list <caml-list@inria.fr>
Subject: Re: [Caml-list] Re: [oss-security] CVE request: Hash DoS vulnerability (ocert-2011-003)
Date: Tue, 13 Mar 2012 13:31:40 +0100 [thread overview]
Message-ID: <CAOOOohQbc1i17tdytamPh5bbW=FNZC2dJSCyyz7vxkf8seB74Q@mail.gmail.com> (raw)
In-Reply-To: <CAPzAKVDFjW3z81hdOTfCyvsVRysc=O6XRe7aq0xK2=Pu2Q5k9A@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 3350 bytes --]
The best compromise to me is to leave the default for Hashtbl, but properly
document this aspect in the manual (with succint explanation and one
relevant pointer). That way:
- you don't break compatibility
- you keep default reproducibility (which is a real feature)
- you teach beginners like myself on tough aspects related to the use of a
datastructure in some frequent use cases.
Having a default randomisation seems much too intrusive to me
(notwithstanding the importance of web programming for ocaml's future ;o))
and for those changes that modify the semantic of a program, you have to be
in control. So I second Paolo's opinion.
However, assuming ocaml users will be "aware of attacks", at least more
than users of other languages, is not only controversial but also non
relevant: there are beginners in ocaml too (who may also be beginners in
programming), and these should be taken care of. A small note in the doc on
the DOS vulnerability that may arise from the use of Hashtbl in a web
application context is enough to protect the users I think, and is of
interest for the casual Hashtbl reader. This note could appear in a
different font/color than the main description of [Hashtbl.create], to
preserve the readability of the docs.
my 2 cent
ph.
2012/3/13 Paolo Donadeo <p.donadeo@gmail.com>
> In my humble opinion, here we have two different vision of what
> computer programming is, or should be. Your statement "maybe it's
> better to assume that the programmer will not be aware of attacks" may
> be true for the average Java programmer (please, no flame, no insult
> intended to Java programmers reading this list!) but not for an OCaml
> programmer. I want to be perfectly aware of attacks, and I want to be
> in control of the data structure I use, and not "be unaware"...
>
> In Python, the other language I use every day, dictionaries are
> implemented as hash tables and not having reproducibility is a PITA.
>
>
> --
> Paolo
>
>
> On Tue, Mar 13, 2012 at 10:54, Romain Bardou <bardou@lsv.ens-cachan.fr>
> wrote:
> > Hi,
> >
> >
> >> As you and Gerd said, the new Hashtbl implementation in the upcoming
> >> major release has everything needed to randomize hash tables by
> >> seeding. The question at this point is whether randomization should
> >> be the default or not: some of our big users who don't do Web stuff
> >> value reproducibility highly... We (OCaml core developers) will take
> >> a decision soon.
> >
> >
> > FWIW, as a developer I do not expect reproducibility from Hash tables
> (nor
> > from the Random module actually) but I do expect some way to control
> > reproducibility (i.e. read the current seed, give my own seed). Maybe
> it's
> > better to assume that the programmer will not be aware of attacks, and
> > provide him with a safer environment.
> >
> > On the other hand, when you find a bug and need reproducibility, it's too
> > late if you have used a random seed without recording it. And could it
> break
> > some existing applications?
> >
> > I guess you('re) already had(having) this discussion though.
> >
> > Cheers,
> >
> > --
> > Romain
>
>
> --
> Caml-list mailing list. Subscription management and archives:
> https://sympa-roc.inria.fr/wws/info/caml-list
> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
> Bug reports: http://caml.inria.fr/bin/caml-bugs
>
>
[-- Attachment #2: Type: text/html, Size: 4323 bytes --]
next prev parent reply other threads:[~2012-03-13 12:32 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <4F3078F1.8070105@redhat.com>
2012-02-07 1:10 ` Kurt Seifried
2012-02-07 8:34 ` Richard W.M. Jones
2012-03-10 7:31 ` Richard W.M. Jones
2012-03-10 12:31 ` Gerd Stolpmann
2012-03-12 18:03 ` Xavier Leroy
2012-03-13 9:54 ` Romain Bardou
2012-03-13 11:58 ` Paolo Donadeo
2012-03-13 12:31 ` Philippe Veber [this message]
2012-03-13 13:23 ` Gerd Stolpmann
2012-03-13 15:39 ` Romain Bardou
2012-03-13 18:27 ` David Allsopp
2012-03-13 18:58 ` Alain Frisch
2012-03-13 18:08 ` Dario Teixeira
2012-03-13 18:28 ` David Allsopp
2012-03-14 9:23 ` Xavier Leroy
2012-03-13 16:52 ` Richard W.M. Jones
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAOOOohQbc1i17tdytamPh5bbW=FNZC2dJSCyyz7vxkf8seB74Q@mail.gmail.com' \
--to=philippe.veber@gmail.com \
--cc=caml-list@inria.fr \
--cc=p.donadeo@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox