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
This archive was generated by hypermail 2b30 : Tue Feb 11 2003 - 09:10:26 PST