Re: safestr alpha (Safe C String Library)

From: John Viega (
Date: 02/11/03

  • Next message: John Viega: "Re: safestr alpha (Safe C String Library)"
    Date: Tue, 11 Feb 2003 08:15:50 -0500
    To: "Giorgio Zoppi (deneb)" <>
    From: John Viega <>

    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

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