Mailing List Archive

> currently log_fatal() ends up invoking exit(2). Is this really the
> right thing to do? It does not give applications using libgcrypt any
> chance to sanely handle fatal errors afaiui, for example by falling
> back on non-tls mode.

Hmm. The reason for exit is probably that log_fatal should be NEVER
called unless something is REALLY fucked up. Especially in crypto
applications it might be the best thing to do, since a serious bug in
the library (or in the program) should not treated like "oh, well, that
crypto feature is currently not available", but rather like "STOP!".

My guess.

Moritz



_______________________________________________
Gcrypt-devel mailing list
Gcrypt-devel@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gcrypt-devel

On Sat, 3 Mar 2007 11:10, ametzler@downhill.at.eu.org said:

> currently log_fatal() ends up invoking exit(2). Is this really the
> right thing to do? It does not give applications using libgcrypt any

Yes. It allows application to run an atexit handler. Libgcrypt even
allows to register a dedicated handler: gcry_set_fatalerror_handler.

In any case the process needs to terminate as their is a fatal error
and something is going really wrong. Allow a process to continue is
not a good idea because it allows bugs to lurk around for years
without fixing. Such a bug is an indicator that something more severe
might have gone wrong.


Shalom-Salam,

Werner


_______________________________________________
Gcrypt-devel mailing list
Gcrypt-devel@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gcrypt-devel

On 2007-03-04 Werner Koch <wk@gnupg.org> wrote:
> On Sat, 3 Mar 2007 11:10, ametzler@downhill.at.eu.org said:

> > currently log_fatal() ends up invoking exit(2). Is this really the
> > right thing to do? It does not give applications using libgcrypt any

> Yes. It allows application to run an atexit handler. Libgcrypt even
> allows to register a dedicated handler: gcry_set_fatalerror_handler.

> In any case the process needs to terminate as their is a fatal error
> and something is going really wrong. Allow a process to continue is
> not a good idea because it allows bugs to lurk around for years
> without fixing. Such a bug is an indicator that something more severe
> might have gone wrong.


Hmm,

in this specific case (libnns-ldap failing due to missing
/dev/(u)random devices in early boot when connecting to the ldap
server using a ssl protected session.) the only thing actually using
gcrypt directly is gnutls.

Should gnutls have setup an error handler using
gcry_set_fatalerror_handler?

cu andreas
--
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'

_______________________________________________
Gcrypt-devel mailing list
Gcrypt-devel@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gcrypt-devel

On Mon, 5 Nov 2007 13:37, md@Linux.IT said:

> I still do not consider calling exit(2) in a library acceptable under
> any condition.

So you want abort () instead? I consider this a bad option in this case
because exit handlers would not be run.

Given the reluctance of many programmers to properly check error codes
and act accordingly, there is no choice in critical situation than to
terminate the process. It was a design decision of the linux kernel to
always provide a /dev/random and it is a design decision of libgcrypt
not to return bad random number - in any case.

BTW, glibc also calls abort if it detects an internal inconsistency.


Salam-Shalom,

Werner


--
Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz.


_______________________________________________
Gcrypt-devel mailing list
Gcrypt-devel@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gcrypt-devel

On Nov 05, Werner Koch <wk@gnupg.org> wrote:

> > I still do not consider calling exit(2) in a library acceptable under
> > any condition.
> So you want abort () instead? I consider this a bad option in this case
> because exit handlers would not be run.
I the function to fail with something like an error code.

> Given the reluctance of many programmers to properly check error codes
> and act accordingly, there is no choice in critical situation than to
> terminate the process.
I still disagree.

--
ciao,
Marco

On Mon, 5 Nov 2007, Marco d'Itri wrote:
> On Nov 05, Werner Koch <wk@gnupg.org> wrote:
>>> I still do not consider calling exit(2) in a library acceptable under
>>> any condition.
>> So you want abort () instead? I consider this a bad option in this case
>> because exit handlers would not be run.
> I the function to fail with something like an error code.
>
>> Given the reluctance of many programmers to properly check error codes
>> and act accordingly, there is no choice in critical situation than to
>> terminate the process.
> I still disagree.

The only way forward I can see from here is to refer the issue to the
Technical Committee. If nobody objects or wants to do it themselves I'll
write up a summary when I have some free time.

--
# TRS-80 trs80(a)ucc.gu.uwa.edu.au #/ "Otherwise Bub here will do \
# UCC Wheel Member http://trs80.ucc.asn.au/ #| what squirrels do best |
[ "There's nobody getting rich writing ]| -- Collect and hide your |
[ software that I know of" -- Bill Gates, 1980 ]\ nuts." -- Acid Reflux #231 /


_______________________________________________
Gcrypt-devel mailing list
Gcrypt-devel@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gcrypt-devel