GnuTLS (libgrypt really) and Postfix

Daniel Carosone dan at geek.com.au
Wed Feb 15 21:14:59 EST 2006


On Tue, Feb 14, 2006 at 04:26:35PM -0500, Steven M. Bellovin wrote:
> In message <87bqx9zm0h.fsf at wheatstone.g10code.de>, Werner Koch writes:
> >I agree.  However the case at hand is a bit different.  I can't
> >imagine how any application or upper layer will be able to recover
> >from that error (ENOENT when opening /dev/random).  Okay, the special
> >file might just be missing and a mknod would fix that ;-).  Is it the
> >duty of an application to fix an incomplete installation - how long
> >shall this be taken - this is not the Unix philosophy.
> 
> It can take context-specific error recovery.  Maybe that's greying out 
> the "encrypt" button on a large GUI.  Maybe it's paging the system 
> administrator.  It can run 'mknod' inside the appropriate chroot 
> partition, much as /sbin/init on some systems creates /dev/console.  It 
> can symlink /dev/geigercounter to /dev/random.  It can load the kernel 
> module that implements /dev/random.  It can do a lot of things that may 
> be more appropriate than exiting.  

Or an even simpler example: maybe it will still be a fatal error, but
there's some important state outside the library being called that it
should clean up before exiting so abruptly.   

Somehow, applications that are consumers of crypto libraries seem like
likely candidates for this sort of thing.

--
Dan.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 186 bytes
Desc: not available
URL: <http://www.metzdowd.com/pipermail/cryptography/attachments/20060216/14734295/attachment.pgp>


More information about the cryptography mailing list