On Mon, Apr 11, 2011 at 10:23 PM, James Reeves <jree...@weavejester.com> wrote: > On 12 April 2011 01:41, Ken Wesson <kwess...@gmail.com> wrote: >> On Mon, Apr 11, 2011 at 7:09 PM, James Reeves <jree...@weavejester.com> >> wrote: >>> You wouldn't necessarily need to explicitly verify each precondition, >>> but it might be the case that the same string is parsed multiple >>> times. However, I'm unsure why you think this is a problem. >> >> I don't. My own code posted earlier parses some strings multiple >> times. > > Okay. But in which case, why do you then say: > >> Either you end up with duplicated code for every >> separate integer range check (bad) > > Why is this bad? I thought we just agreed that there's no particular > problem in parsing the same thing multiple times?
There's a difference between the program parsing the same *object* multiple times, and the program's own source code containing duplication! >>> But it's compound by necessity, and has a >>> singular purpose - to validate a particular object. >> >> So's mine. > > Not really. Yes, really, as I've already explained. > (defn validate-user [user] > "Validates parameters describing a user." > (validate user > [:email present? "must be present"] > [:email email-address? "must be a valid email address"] > [:password present? "must be present"])) > > Although this is a complex function, we can describe everything a > developer needs to know about this function in one sentence. You don't > need to know what validations are in this function in order to use it, > and as long as you know the type of map the `validate` function > returns, you need no more information. > > But your not-int-in-range? cannot be described in such simple terms, > because any developer using it would need to know which keywords it > returns, and under what circumstances it returns them. A doc-string > for your function would necessarily be much longer: > > (defn not-int-in-range? [x min max] > "Determines if an string, x, representing an integer fall between > the numbers min and max. If x is blank, :blank is returned; if > x does not contain an integer, :non-integer is returned; if x is > too low, :low is returned; if x is too high, :high is returned; if > x represents an integer that falls between the range min to max, > then false is returned." > ...) Actually, nil is returned. And you're cheating. Your "validate" function is presumably as complex. The same information ends up in its docstring, or distributed among present?, email-address?, and the like. Moving the complexity around or sweeping it under various rugs does not make it go away. The fact is, a nominal integer from 1 to 120 gets checked for being present, being an integer, being greater than zero, and being less than 121. There's no way around that. The bits of that can be moved around but not gotten rid of, and anything that checks for an input to be an integer in that range will bring those parts all together. > The simplicity of a function is more a question of what it does, than > how it does it. And any function that validates range-limited integer inputs ends up checking the same four things. >>>> If you forget to do *anything* in a security-critical system, that's a >>>> potential security risk. >>> >>> If you forget a "deny" rule, that's a potential security risk, but if >>> you forget an "allow" rule, it usually isn't. >> >> But it sometimes is. > > I didn't say otherwise. You were claiming that forgetting *anything* > would cause a security risk I was not. I only claimed that forgetting anything *could* cause a security risk, depending on the system. >> But, but, but. You made a universal statement that I've proven was >> wrong. You've basically admitted this by admitting that there are any >> exceptions at all to your "universal" rule. So, why keep arguing? > > What universal statement are you talking about? You made a blanket claim that deny-by-default is superior. >> Again, that depends on the system and on what you mean by "secure". Is >> "deny all" a sensible default when designing MP3 player firmware? >> "Security" in such a context means "nobody unauthorized can screw with >> my music storage, organization, and playback". Things not working >> would be the player's manufacturer having effectively screwed with >> your music storage, organization, and playback. > > That's the strangest definition of "unauthorized access" I've ever heard. > > The authorised user is the one who owns the device. Whilst it's being > manufactured, the manufacturer owns the device, so you can't describe > anything the manufacturer does during that period as being > unauthorized. However, after the eventual owner has bought the device, anything the manufacturer did that gratuitously limits functionality may well be unauthorized by that new owner. > If the manufacturer created the MP3 player, sold it to you, and *then* > remotely bricked it, you'd have a case of unauthorized access. But if > the manufacturer bricks the player *before* you become the authorized > user, then it's not unauthorized access. You're viewing it the wrong way. Once a new owner takes possession of the device, that new owner should decide its policy. If the old owner's policies keep intruding after that point, that's unauthorized. The new owner *should* be able to obliterate and replace any such policies. If they cannot, the dead hand of the old one has in effect intruded. The new owner is prevented from using the device as they wish due to actions taken by the old owner (whose sole recourse, if the manufacturer, regarding undesired usage should be the voiding of the warranty). Put in simpler language: once I buy it, I should not be bound by Sanyo's (or whoever's) policies (except for their policy regarding under what circumstances they'll continue to honor a warranty, since that involves an obligation they voluntarily accept and can relinquish rather than an imposition on my ow use); only by the inherent physical limitations of the device and the correct bounds of its functionality. If it won't play .ogg files, and it was not supposed to, fine. If it won't play Jann Arden mp3s because Sanyo doesn't like Arden, that's a problem. Sanyo's reduced the functionality of the device in a manner not authorized (unless this "limitation" is clearly stated up front at the time of purchase, so I implicitly authorized it by purchasing it despite knowledge of the "limitation"). >> There is no single right answer here that is >> independent of the application's basic nature and use context! > > There may be a case where an erroneous validation error results in a > security flaw, but But, but, but. > In my experience, "deny-by-default" is the right answer in less than 100% of cases. -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
