Re: Core dump caused by misusing openssl in multithread scenario!

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



2012/10/8 Benjamin Wang (gendwang) <gendwang@xxxxxxxxx>:
> -----Original Message-----
> From: Matthias Bolte [mailto:matthias.bolte@xxxxxxxxxxxxxx]
> Sent: 2012年10月7日 2:14
> To: Benjamin Wang (gendwang)
> Cc: Daniel P. Berrange; libvir-list@xxxxxxxxxx; Yang Zhou (yangzho)
> Subject: Re:  Core dump caused by misusing openssl in multithread scenario!
>
> 2012/10/2 Benjamin Wang (gendwang) <gendwang@xxxxxxxxx>:
>> Hi Daniel,
>>    Is this problem fixed in the latest version? What about the question 2 which related to openssl callbacks in multi-thread?
>
> As Daniel said, we cannot assume that libcurl was build with OpenSSL backend. We would need some way to detect this first.
> [Benjamin]: I agree. But if libcurl want to access ESXi by https. OpenSSL will be used. And libvirt must call CRYPTO_set_id_callback/CRYPTO_set_locking_callback
> to support multi-threads

This is not completely true. libcurl can be compiled with different
SSL backends. OpenSSL is only one of them. As Daniel said there are
many of them. Current libcurl supports OpenSSL, GnuTLS, NSS, qssl,
CyaSSL, PolarSSL and axTLS as SSL backends. That's why we cannot make
assumptions about which SSL backend is used by a specific instance of
libcurl.

You're probably right that if OpenSSL is used libvirt should provide
the required multi-threading functions. But this requires that we can
detect which SSL backend is used by libcurl library that is linked to
libvirt.

> Also, wasn't there a license problem with OpenSSL and the (L)GPL? Can libvirt legally be used with a libcurl that is linked with OpenSSL?
> [Benjamin]: I think there is no open source license issue. We will not change libcurl or openssl source code. What we needed is to call openssl API(CRYPTO_set_id_callback/CRYPTO_set_locking_callback)
> to support multi-threads.

If OpenSSL is actually incompatible to the (L)GPL then it cannot be
used in combination with libvirt.

This statement (if it is true) is independent of changing libcurl or
OpenSSL code. The problem here will be that libcurl itself uses the
MIT license which is compatible with the (L)GPL. But libcurl linked to
OpenSSL might be not because OpenSSL's license might not be (L)GPL
compatible. This whole point is only about what licenses can legally
be mixed in a single project and this doesn't dependent on changing
any code or not. The point of libvirt calling OpenSSL functions is the
same problem.

-- 
Matthias Bolte
http://photron.blogspot.com

--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list



[Index of Archives]     [Virt Tools]     [Libvirt Users]     [Lib OS Info]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]     [Fedora Tools]