seg fault in crypto.h code

[Simon Josefsson]

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

> On Fri, Apr 25, 2008 at 1:18 PM, Simon Josefsson <simon at josefsson.org> wrote:
>> "Nikos Mavrogiannopoulos" <n.mavrogiannopoulos at gmail.com> writes:
>>
>> > I'll check it. This weekend I'll have some free time (btw. the mpi and
>> > pk interface are also pretty much ready -no testing though).
>
>> I'm beginning to think that we shouldn't push this into gnutls 2.4.  I
>> want to get v2.4 out in the next few weeks (it is already almost a month
>> late).  Adding the mpi/pk stuff, and having little or no testing of the
>> overall crypto.h stuff, and no self-tests, and no plan to handle the
>> multithread concerns, all seems likely to cause further delays.
>
> And I also agree. Put the code in an #if 0 (also the header) before
> release.

I'll do this soon.

> About the multithreaded issue, I don't believe it is an issue. The
> registration should happen once after global_init. It is not an api to
> call at any time during execution.

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.

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.

>> So, please, push your mpi/pk work to a separate branch.
>
> It is on a separate branch.

Great.

/Simon