caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
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 --]

  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;
as well as URLs for NNTP newsgroup(s).