Date: Mon, 29 Apr 2013 23:55:00 +0200 From: Szabolcs Nagy <nsz@...t70.net> To: musl@...ts.openwall.com Subject: Re: High-priority library replacements? * Gregor Pintar <grpintar@...il.com> [2013-04-29 19:35:03 +0200]: > > (eg hash_update(ctx, buf, len) should never fail > > even if there is a counter in ctx that can overflow > > every 2^64th bit of input, documenting the behaviour > > for longer inputs is better, it would be even better > > if the apropriate standards were more careful about > > failures) > Devs that ignore return values would probably ignore documentation too. i think the problem is not ignorance, but the combinatorial explosion of code paths which increases bug probability in my view the purpose of error codes is to indicate runtime errors (eg allocation or io failures) and not to prevent bugs in the program logic (there are other tools for that, most notably the type checker, adding extra error handling paths for bug prevention usually makes things worse) returning an error code when some inconsistency is detected seems simple, but error semantics are usually not trivial: is it enough to retry, or retry with different parameters or treat the failure as fatal, should all the related states be cleaned if they might contain sensitive data or would the library do this for us, how to report the error on the ui etc without documentation the user should prepare for the worst and that can easily turn into a harder problem than implementing sha1 from scratch > Encrypting more than 2^(block size) / 2 of blocks is broken too. that's why cryptographers should choose the block size wisely so the user does not have to worry about it
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.