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 q2DFe27L028698 for ; Tue, 13 Mar 2012 16:40:02 +0100 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApEDAMJpX09beT4LnGdsb2JhbABDslyDKQEBAQEBCAsSFCeCCgEFMgEFQBELIRYPCQMCAQIBRRMIAogGBLxUjUODIgSbW4x+ X-IronPort-AV: E=Sophos;i="4.73,577,1325458800"; d="scan'208";a="135849349" Received: from 15.mo4.mail-out.ovh.net (HELO mo4.mail-out.ovh.net) ([91.121.62.11]) by mail4-smtp-sop.national.inria.fr with ESMTP; 13 Mar 2012 16:39:56 +0100 Received: from mail97.ha.ovh.net (b7.ovh.net [213.186.33.57]) by mo4.mail-out.ovh.net (Postfix) with SMTP id A02DF105891E for ; Tue, 13 Mar 2012 16:43:16 +0100 (CET) Received: from b0.ovh.net (HELO queueout) (213.186.33.50) by b0.ovh.net with SMTP; 13 Mar 2012 17:39:56 +0200 Received: from unknown (HELO ?138.231.81.152?) (romain%bardou.fr@138.231.81.152) by ns0.ovh.net with SMTP; 13 Mar 2012 17:39:48 +0200 Message-ID: <4F5F6A44.2070601@lsv.ens-cachan.fr> Date: Tue, 13 Mar 2012 16:39:48 +0100 From: Romain Bardou User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.24) Gecko/20111114 Icedove/3.1.16 MIME-Version: 1.0 To: caml-list@inria.fr X-Ovh-Mailout: 178.32.228.4 (mo4.mail-out.ovh.net) 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> <4ec32a156daa6211ca4d465c9a7b8745.squirrel@gps.dynxs.de> In-Reply-To: <4ec32a156daa6211ca4d465c9a7b8745.squirrel@gps.dynxs.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Ovh-Tracer-Id: 7657245266702620448 X-Ovh-Remote: 138.231.81.152 () X-Ovh-Local: 213.186.33.20 (ns0.ovh.net) X-OVH-SPAMSTATE: OK X-OVH-SPAMSCORE: 0 X-OVH-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrfeegvddrfeehucetggdotefuucfrrhhofhhilhgvmecuqfggjfenuceurghilhhouhhtmecufedttdenucenucfhrhhomheptfhomhgrihhnuceurghrughouhcuoegsrghrughouheslhhsvhdrvghnshdqtggrtghhrghnrdhfrheqnecujfgurhepkfffhfgfggfvufhfjggtgfesthekrgdttdefud X-Spam-Check: DONE|U 0.5/N X-VR-SPAMSTATE: OK X-VR-SPAMSCORE: 0 X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrfeegvddrfeehucetggdotefuucfrrhhofhhilhgvmecuqfggjfenuceurghilhhouhhtmecufedttdenucenucfhrhhomheptfhomhgrihhnuceurghrughouhcuoegsrghrughouheslhhsvhdrvghnshdqtggrtghhrghnrdhfrheqnecujfgurhepkfffhfgfggfvufhfjggtgfesthekrgdttdefud X-Validation-by: bardou@lsv.ens-cachan.fr Subject: Re: [Caml-list] Re: [oss-security] CVE request: Hash DoS vulnerability (ocert-2011-003) Le 13/03/2012 14:23, Gerd Stolpmann a écrit : > >> 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. > > Basically I like the idea of "teaching" users this way. The typical user > will understand the impact, and act accordingly. Nevertheless, I would > like it if it would be made as easy as possible to provide good seeds if > required. The Random module is definitely not good enough (e.g. if you > know when the program was started like for a cgi, and the cgi reveals > information it should better not like the pid, the Random seed is made > from less than 10 unpredictable bits, and on some systems even 0 bits). > > The ideal would be to guide the user to the decision whether protection is > necessary, and if the answer is yes, to give the instructions how to do it > (and provide all means for it, of course). This teaching idea sounds great indeed, but on the other hand, where do we draw the line? If we push this reasoning too far, we could remove typing altogether and just tell the programmer to be careful. What is the difference here? Is a potential DoS attack "less bad" than a seg fault? So although the idea of teaching the programmer through the documentation makes sense, I would put it the other way around: make the safer behavior the default, and give debugging tools with proper warnings. Here the tool is a "set_seed" function and the warning is in its documentation: "using the same seed everytime can lead to DoS attacks". That being said I don't really care that much, I'm just thinking out loud here :p Cheers, -- Romain Bardou