seg fault in crypto.h code

[Simon Josefsson]

Nikos Mavrogiannopoulos <n.mavrogiannopoulos at gmail.com> writes:

> Simon Josefsson wrote:
>
>> The problem I see is that libgnutls could be used by libraries, and they
>> may not be aware of each other.  Consider:
>> 
>> threaded application
>> ---> library 1
>>        -> register a crypto.h handler
>>        -> gnutls_global_init
>> ---> library 2
>>        -> register a crypto.h handler
>>        -> gnutls_global_init
>> 
>> I'm not sure what the expected behaviour should be in this situation.
>> Any crashes should be avoidable, of course, but it may be (too?)
>> surprising for library 1 to not use the crypto.h functions it
>> registered.
>
> Each one registering a handler, associates with a priority number. On
> execution time the one with lowest priority is run. In case of a
> conflict (priority number reuse or registering with higher priority than
> an existing handler) the registration will fail.

Ok.  In any case, since these interfaces are optional, as long as we
document the caveats properly, people could decide for themselves if
they are safe to use for what they are using it for.

I'm not sure many applications need to replace the crypto functions
during run-time, but I could be wrong.

>> This was my reason for doing a compile-time (rather than run-time)
>> decision via the gnulib gc-* stuff, but alas that was never finished for
>> pk/mpi.
>
> The approach I followed in pk/mpi will allow for both compile time and
> runtime decision. Once finished I'll rewrite the logic in
> hash/cipher/rnd to be similar in mind.

Great!

/Simon