Re: High-priority library replacements?

[Szabolcs Nagy <nsz@port70.net>]

* Gregor Pintar <grpintar@gmail.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