Re: safestr alpha (Safe C String Library)

On Tuesday, February 11, 2003, at 09:00 AM, Giorgio Zoppi (deneb) wrote:

> On Tue, Feb 11, 2003, John Viega wrote:

No, I disagree strongly. The whole idea of the library is to ease the burden of the programmer. He or she should be able to process strings in a secure manner without having to give any thought to it. For this reason, I am 100% unwilling to offload any potentially security-critical responsibility to the user by default.

>> When potentially security-critical problems come up, I would rather

Those languages have their own string types that are going to give you the same properties. There's no good reason to wrap the library into such a language.

And, the way we intend on handling this issue is by allowing you to explicitly set a callback, into which will be passed the string that failed, a representation of the operation that failed, and some indication of what failed. Even if you were to write a wrapper for one of those languages, you would simply write your own error handler that wraps up that information and then throws an exception.

>
>> We are leaning toward providing a callback for when a "fatal" error

Do you need help?

In addition to our free technical library, Pantek provides professional IT services to companies who utilize Open Source software: Learn more about Pantek's Technical Support offerings Place an order for 24/7/365 Technical Support here Learn more about Pantek, who we are, and what we do Chat with a Live Operator Related securityfocus.com Links bugtraq certification focus-bsd focus-ids focus-ih focus-linux focus-ms focus-sun focus-unix-other focus-virus forensics incidents libnet linux-secnews ms-secnews pen-test secpapers secprog sectools secureshell security-basics securityjobs sf-news vuln-dev webappsec Request more information about Pantek

Again, we will not use error-passing mechanisms that need to be checked explicitly when there are security-critical concerns. That would explicitly thwart the goals of writing it.

HOWEVER, another solution that we've considered is moving the main API to be 100% macro-based. The underlying API would all pass error parameters around. Then, the macros would seamlessly do the error checking, and could still be written in such a way as to call application-specific handlers (for example, by replacing the macros; we could provide multiple sets of macros by default).

The advantage of such a mechanism is that, when you do want to override the behavior, it's much easier to get the context in which a failure occurred. But then we'd be publicly exporting an API that has the potential for misuse, and would have to hope that people don't use it. Plus, the solution feels pretty messy on the whole, and is not very satisfying.

Anyway, like I said, we are thinking about it, and will have a solution in place before too long.

John Received on Tue Feb 11 12:11:08 2003