Re: safestr alpha (Safe C String Library)

• Previous message: Giorgio Zoppi (deneb): "Re: safestr alpha (Safe C String Library)"
• In reply to: Giorgio Zoppi (deneb): "Re: safestr alpha (Safe C String Library)"
• Next in thread: John Viega: "Re: safestr alpha (Safe C String Library)"
• Reply: John Viega: "Re: safestr alpha (Safe C String Library)"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]

Date: Tue, 11 Feb 2003 08:15:50 -0500
To: "Giorgio Zoppi (deneb)" <deneb@penguin.it>
From: John Viega <viega@securesoftware.com>

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

> On Tue, Feb 11, 2003, John Viega wrote:
>
>> Yes, we're still trying to figure out the mechanism via which we want
>> to handle such things. The big problem with returning error codes,
>> etc. is that there's a strong tendency to ignore results than indicate
>> an error.
>
> Yes, you should not care about this issue. It's not your fault,
> if the programmer, that has this tendency, should waste his time
> in a more productive way.

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
>> just see the program die if there's any significant chance of the
>> programmer failing to check the error condition and leaving the
>> program
>> in an insecure state.
>
> But this limits the library functionality, if for example do I wish use
> your library in my Perl/Python/PHP wrapper?

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
>> occurs. The default will be to print an error message and abort.
>> This
>> solution gives the programmer some flexibility, and even avoids
>> needlessly adding a bunch of additional error conditions to check. On
>> the down side, it can be difficult to figure out the exact context of
>> failure and recover gracefully.
>
> Or in a more simple way (even if it's not smart):
> ...

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

• Next message: John Viega: "Re: safestr alpha (Safe C String Library)"
• Previous message: Giorgio Zoppi (deneb): "Re: safestr alpha (Safe C String Library)"
• In reply to: Giorgio Zoppi (deneb): "Re: safestr alpha (Safe C String Library)"
• Next in thread: John Viega: "Re: safestr alpha (Safe C String Library)"
• Reply: John Viega: "Re: safestr alpha (Safe C String Library)"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]