GnuTLS (libgrypt really) and Postfix

[John Denker]

David Wagner wrote:

> This just shows the dangers of over-generalization.

One could make an even stronger statement about the dangers of
making assumptions that are not provably correct.

> Of course, we have to decide which is more important: integrity,
> or availability.  

That is a false dichotomy.

> I suspect that in the overwhelming majority (perhaps
> all) of the cases where libgcrypt is used, integrity is more important
> than availability.  If that is true, well, if in doubt, it's better to
> fail closed than to fail open.

Again:  False dichotomy is a fallacy, and has been recognized for
 >2000 years as such.  Showing that one extreme is bad does not
prove that the opposite extreme is good.

The whole point of my previous note was to argue for more nuanced
handling.  Progressing from one knee-jerk handing to a choice
between two knee-jerk handlings is not much progress.


> I think the attitude that it's better to die than to risk letting an
> attacker take control of the crypto library is defensible, in many cases.

Again, that's the wrong question;  it's not an either/or proposition.
We can agree that letting the attacker take control of the situation
is a Bad Thing, but it is preposterous to think that exiting is
provably correct in all situations where the library might be put
to use.

It is just plain arrogant for low-level code to arrogate to itself
a decision that rightfully belongs to higher-level code.


Werner Koch wrote in part:

>> Sure, for many APIs it is posssible to return an error code but this
>> requires that the caller properly checks error codes.  We have all
>> seen too many cases were return values are not checked and the
>> process goes ahead assuming that everything went well 

That is narrowly true as stated, but it does not prove that exiting
is the correct thing to do.

That might lead to an argument in favor of exceptions instead of error
codes, along the following lines:
  -- Naive code doesn't catch the exception.  However (unlike returned
   error codes) this does not cause the exception to be lost.
  -- The exception percolates up the call-tree until it is caught by
   some non-naive code (if any).
  -- If all the code is naive, then the uncaught exception terminates
   the process ... to the delight of the "exit on error" faction.
   However (!!!) unlike a plain old exit, throwing an exception leaves
   the door open for non-naive code to implement a nuanced response to
   the exceptional condition.

Again, enough false dichotomies already!  Just because error codes are
open to abuse doesn't mean exiting is the correct thing to do.


---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com