RE: OpenLDAP-specific API

["Howard Chu" <hyc@highlandsun.com>]

> -----Original Message-----
> From: owner-openldap-software@OpenLDAP.org
> [mailto:owner-openldap-software@OpenLDAP.org]On Behalf Of Dave Horsfall

> > The rule for the OpenLDAP project is correctness first,
> > performance second.
>
> I'd rather see security ahead of correctness, or is that just me?  Your
> code can be both correct and fast, but it's useless to me if it opens up
> a potential attack.

I think you missed the point of my post. Code that is vulnerable to buffer
overrun attacks cannot by any measure be considered correct. In that respect,
security and correctness are one and the same. I was not defining
"correctness" in my previous post.

My main point, stated another way - the current trend of only looking at the
interface is irresponsible. This is the standard paradigm of C++, Java, and
other object-oriented programming languages, and it is Wrong. Object-oriented
*design* is a very powerful, useful design methodology - it lets you analyze
a large, complex problem by breaking it into smaller, more manageable
subproblems. But it is a conceptual tool only; an OO design does not and
should not map one-to-one into code. When it comes time to implement code for
the subproblems, you have to remain fully aware of how each module works. If
you just blindly use a class library that someone else has created for you,
without looking at how it works, you will inevitably wind up trying to use it
in a way it was not intended, or a way that it handles very poorly. So in my
very simple example, if you just blindly use strcat to concatenate DNs
together all the time, without realizing that strcat always starts from the
beginning of the string and thus takes exponentially longer to execute the
longer your DNs are, your programs will perform badly.

Since you raise the question though, I would also assert that OO programming
practices not only encourage bloated, badly performing code, but also
encourage the creation of more insecure code. When you are encouraged to be
lazy enough not to bother looking at what a borrowed class does, there is
very little likelihood that you will ever see anything it does wrong under
the covers. For example, one of the principles of programming for password
security is to keep the password in accessible memory for as small an amount
of time as possible. When you use a language like Java that does garbage
collection, you have no idea what happens to that string you just copied a
password from, after it goes out of scope, or after you invoke its
destructor. It could be sitting around doing nothing, or it could be
coalesced into some range of memory that is handed off to an entirely
separate thread, and pumped onto the network as the trailing
garbage/uninitialized field of a message header. You have no idea, and most
of the time, you won't even care.

As programmers, you *should* care, and you should *know* what the code you
work with does, and how it does it. That is my point.

  -- Howard Chu
  Chief Architect, Symas Corp.       Director, Highland Sun
  http://www.symas.com               http://highlandsun.com/hyc
  Symas: Premier OpenSource Development and Support