[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
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.
