On Mon, Jan 02, 2012 at 12:58:03AM +0100, Gerd Stolpmann wrote: [...] > > > What I could imagine is a module Sys.Security where all security > > > features are accessible and configurable, e.g. > > > > I doubt that this makes sense. > > Nearly anything that can be programmed can become a security > > issue, if done wrong; especially things done on the > > operating system level (like Unix module) could become > > a security issue, if things are handled without care. > > Thanks for your argumentative help - by being ignorant you prove my > thesis that typical programmers won't do anything by themselves. The > world is so much trouble, better put the head into the sand, and hope > the attacker won't pick you. (Well, sorry, maybe a bit too harsh, but I > hope you get my point that it is no excuse that also other security > issues may exist). [...]
You completely did NOT see what I talked about. I did not say, this problem should be ignored. At the day when I heard from this bug I also was tempted to post to this list here; just someone was faster then me. What I meant was not to ignore the problenm, because there are other problems; I meant, that there is no reason to ship the functionality into Sys.Security, if it belongs to Hashtbl. As you said, it is necessary to point the attention of the programmer to crucial points, this means, that the Hashtbl-Initialization needs to be in the Hashtbl module. The docs for the Hashtbl are the place, where a programmer looks for information on Hashtbles of course, and not in some module in any other place. Especially if the progranmmer is not aware of the problem, it's a necessity to place the information at the place of the module that you want to use. This is good style of documentation and also is rather FPL like. Exporting the Seeds-functionality to some other module is very similar to using global variables in a C program. Put the things where they belong to. And Hashtbl-init belongs to Hashtbl-module. [...] > > A mandatory (not optional) hash-function-parameter > > that must be passed (plus some default hash functions > > with elaborated documentation on the properties of those) > > would make more sense to me. > > The seed is so far optional. Sure, requiring it mandatorily would ensure > it is passed, but I guess programmers would just become used to the > idiom "Hashtbl.create ~seed:0 ()". If the type is an abstract type, which comes from something like Hashtbl.Randomseed and has type t, not type int, this problem would vanish. [...] > > Putting things that need tp be part of the Hash-module > > aside into a Sys.security-module makes these things less > > apparent to the programmer who just wants to use hashes, > > and don't thinks about using hashes might be a security problem. > > If done right, this won't be a problem anymore for the typical user (who You also mentioned, that programmers might be too lazy or are not aware of the problem. Then putting the initialization to some unrelated module is not supporting the programmer to become aware of the problem. Even if the person already knows that there might be some security issues with the hashtables, then I doubt, that the first idea of most programmers would be to look out for something like Sys.Security. Instead I would assume higher frequency of asking mails on this list, about this problem. Ciao, Oliver -- 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
