From mboxrd@z Thu Jan 1 00:00:00 1970 X-Sympa-To: caml-list@inria.fr Received: from mail4-relais-sop.national.inria.fr (mail4-relais-sop.national.inria.fr [192.134.164.105]) by walapai.inria.fr (8.13.6/8.13.6) with ESMTP id q2DCW011022063 for ; Tue, 13 Mar 2012 13:32:02 +0100 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Au8CAM88X0/RVdy2mGdsb2JhbABDpA+IVQGIcwgiAQEBAQEICQ0HFCeCCQEBAQMBEgIsARsSCwEDAQsGBQsDCg0hIQEBEQEFAQoSBhMSEIdjBQufFwqLeIJxhS0/iHQBBQuJN4cjBIJeknGLK4MaPYQH X-IronPort-AV: E=Sophos;i="4.73,575,1325458800"; d="scan'208";a="135806672" Received: from mail-vx0-f182.google.com ([209.85.220.182]) by mail4-smtp-sop.national.inria.fr with ESMTP/TLS/RC4-SHA; 13 Mar 2012 13:32:01 +0100 Received: by vcmm1 with SMTP id m1so1150926vcm.27 for ; Tue, 13 Mar 2012 05:32:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=ZxrL4KBZFq8JL+/8ZKl0VPEUNg8oeRrl3jKewMKyZPY=; b=g7ucGPimA4J8F6NBepYexuBrGkCT0HN4shqInH1n49RQRZCt+LhlzoHH8//xfvF/Qd NQWVO6AHk5A1OUl+mF6GbOk1gNFwkf4bX6/0Kqu1qxnmf3L0vvgYXLvb0dGaxj++uuDQ 4LFEDUZNXcCHCeJtvnezbAhdoNrI1yFEhg/xmJqWmA2WHjKKnaGnfROFpudPt69uz4iS dhM3HdLG/6ZBud6qnlhQE6JjnzOax2MYRq1h5QMWMHQkxAJP+L8Pro6AVdQn/+MyhLUF rOO1QH4nT29Yu24cHQlMf+Wesa+ipnzaeqdF6nNlHg4OoHgUXc6vD8ggYuzdyIX64I/y 5SVw== Received: by 10.52.173.38 with SMTP id bh6mr16529217vdc.43.1331641920229; Tue, 13 Mar 2012 05:32:00 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.112.201 with HTTP; Tue, 13 Mar 2012 05:31:40 -0700 (PDT) In-Reply-To: References: <4F3078F1.8070105@redhat.com> <4F3079F7.4040606@redhat.com> <20120207083412.GA30350@annexia.org> <20120310073113.GA16716@annexia.org> <4F5E3A6E.4010406@inria.fr> <4F5F1968.20600@lsv.ens-cachan.fr> From: Philippe Veber Date: Tue, 13 Mar 2012 13:31:40 +0100 Message-ID: To: Paolo Donadeo Cc: OCaml mailing list Content-Type: multipart/alternative; boundary=bcaec517c4fc9f901604bb1f0bfe X-Validation-by: philippe.veber@gmail.com Subject: Re: [Caml-list] Re: [oss-security] CVE request: Hash DoS vulnerability (ocert-2011-003) --bcaec517c4fc9f901604bb1f0bfe Content-Type: text/plain; charset=ISO-8859-1 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 > 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 > 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 > > --bcaec517c4fc9f901604bb1f0bfe Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
The best compromise to me is to leave the default for Hashtbl, but prop= erly document this aspect in the manual (with succint explanation and one r= elevant 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 randomisa= tion seems much too intrusive to me (notwithstanding the importance of web = programming for ocaml's future ;o)) and for those changes that modify t= he 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 als= o 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 do= c 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 inter= est for the casual Hashtbl reader. This note could appear in a different fo= nt/color than the main description of [Hashtbl.create], to preserve the rea= dability of the docs.

my 2 cent
ph.

2012/3/13 Paolo Dona= deo <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<= br> 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 upcomi= ng
>> major release has everything needed to randomize hash tables by
>> seeding. =A0The question at this point is whether randomization sh= ould
>> be the default or not: some of our big users who don't do Web = stuff
>> value reproducibility highly... =A0We (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= 9;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. =A0Subscription 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


--bcaec517c4fc9f901604bb1f0bfe--