On 12 April 2011 04:31, Ken Wesson <kwess...@gmail.com> wrote:
> There's a difference between the program parsing the same *object*
> multiple times, and the program's own source code containing
> duplication!
But there isn't any duplication:
(defn present? [x]
(not (string/blank? x)))
(defn- parse-int [x]
(try (-?> x Integer/parseInt)
(catch NumberFormatException _ nil)))
(defn integer-string? [x]
(boolean (parse-int x)))
(defn over [n]
(fn [x] (-?> (parse-int x) (> n))))
Unless you're asserting that calling parse-int twice is code duplication?
> 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.
But as a developer who is using the API, why should I care what
validations the "validate-user" applies, so long as those validations
are correct?
We seem to have different ideas about what complexity is at this
point. My assertion is that the internal complexity of a function does
not matter, but the complexity of its return values and arguments
does.
If we disagree on that fundamental point, we probably should just
agree to disagree.
> And any function that validates range-limited integer inputs ends up
> checking the same four things.
Yes, but not necessarily in a divisible fashion.
> I was not. I only claimed that forgetting anything *could* cause a
> security risk, depending on the system.
Looks like I misinterpreted you, then.
>>> 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.
Now you're misinterpreting me :)
There may conceivably be a situation where deny-by-default is less
secure than allow-by-default. However, I cannot think of such any such
scenario, and I've never encountered or heard of any such scenario
arising in practise. It's therefore my opinion that deny-by-default is
the best option in at least 99% of cases.
> 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.
That's a very strange definition of what unauthorised access constitutes.
Assuming no-one (including the manufacturer) was able to access the
device, I'd consider the device to be very secure - just utterly
useless.
>> In my experience, "deny-by-default" is the right answer in
>
> less than 100% of cases.
I didn't say that. "At least 99%" is not necessarily "less than 100%".
In any case, I don't understand your objection. If you accept that in
the majority of cases, deny-by-default is the best choice, then surely
it's the best default security policy?
- James
--
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
