GnuTLS (libgrypt really) and Postfix

Ben Laurie ben at algroup.co.uk
Wed Feb 15 12:51:34 EST 2006


Steven M. Bellovin wrote:
> In message <43F14417.1000307 at echeque.com>, "James A. Donald" writes:
>>     --
>>
>>>> Libgcrypt tries to minimize these coding errors; for example there
>>>> are no error returns for the RNG - if one calls for 16 bytes of
>>>> random one can be sure that the buffer is filled with 16 bytes of
>>>> random.  Now, if the environment is not okay and Libgcrypt can't
>>>> produce that random - what shall we do else than abort the process.
>>>> This way the errors will be detected before major harm might occur.
>>>   I'm afraid I consider it instead a weakness in your API design
>>>   that you
>>> have no way to indicate an error return from a function that may
>>> fail.
>> The correct mechanism is exception handling.
>>
>> If caller has provided a mechanism to handle the failure, that
>> mechanism should catch the library generated exception.  If the caller
>> has provided no such mechanism, his program should terminate
>> ungracefully.
>>
>> Unfortunately, there is no very portable support for exception
>> handling in C.   There is however support in C++, Corn, D, Delphi,
>> Objective-C, Java, Eiffel, Ocaml, Python, Common Lisp, SML, PHP and
>> all .NET CLS-compliant languages.
>>
>> Absent exception handling, mission critical tasks should have no
>> exceptions, which is best accomplished by the die-on-error standard.
>>
> 
> Precisely.  I was preparing a post of my own, saying the same thing; 
> you beat me to it.
> 
> We all agree that critical errors like this should be caught; the only 
> question is at what layer the action should take place.  I'm an 
> adherent to the Unix philosophy -- when a decision is made at a lower 
> level, it takes away the ability of the higher level to do something 
> different if appropriate, and this loss of flexibility is a bad thing.

I have perhaps not been clear in some of my comments in this thread. I
think there is a world of difference between critical errors and
detecting internal inconsistency. In the case of inconsistency I claim
that it is _never_ correct to continue running because every instruction
executed is another potential hole for the attacker to use.

Critical errors which do not indicate that something unexpected (as
opposed to undesirable) has happened should, indeed, allow the caller to
decide how they are handled.

Cheers,

Ben.

-- 
http://www.apache-ssl.org/ben.html       http://www.thebunker.net/

"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff

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



More information about the cryptography mailing list