Re: safestr alpha (Safe C String Library)

From: John Viega (viega@securesoftware.com)
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)" <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



    Relevant Pages

    • Re: Catagories of Assembly Languages
      ... use LuxAsm without the ... programmer due to ignorance...oh, we'll be glad to help to try to resolve ... implementation and that the LuxAsm team does not mandate that such macros ... assembler is concerned while processing your source file (yes, ...
      (alt.lang.asm)
    • Re: Which programming language is better to start
      ... LISP macros are unsafe whereas camlp4 is not. ... Don't try to argue that dynamic typing is high-level. ... > especially compared to languages with required explicit declarations. ... > Common Lisp's condition system gives the programmer much more control ...
      (comp.programming)
    • Re: Lisp development with macros faster than Python development?..
      ... programmer can whip up in a few minutes. ... documented macros, functions and classes that the programmer can ... > He claims he developed a web app at light speed using Lisp and lots ... > It got me curious if Lisp ...
      (comp.lang.python)
    • Re: Lisp benefits against other functional programming languages
      ... > evaluation in some cases) that's the reason for a need of a macro ... among the programmer population are superfluous. ... macros go way beyond that; ... > Haskell without macros. ...
      (comp.lang.lisp)
    • Re: Createing linked forms: "Object is closed or doesnt exist"
      ... How do you make queries and such available for use in forms? ... that forms and macros lock into but I have yet to find this. ... I am mainly an Oracle programmer and now working in Access ... you can use a VBA procedure to open a ...
      (microsoft.public.access.modulesdaovba)