| 1 |
On Wed, 01 Dec 2010 22:44:45 +0100 |
| 2 |
Diego Elio Pettenò <flameeyes@×××××.com> wrote: |
| 3 |
|
| 4 |
> Il giorno mer, 01/12/2010 alle 22.30 +0100, Michał Górny ha scritto: |
| 5 |
> > |
| 6 |
> > In other words, the preferred complete build of ekg2 requires both |
| 7 |
> > gnutls and openssl. However, all of the features should work fine |
| 8 |
> > with openssl itself as well. |
| 9 |
> > |
| 10 |
> There is a simple first question to ask here. Does it use pure GnuTLS |
| 11 |
> or the GnuTLS-OpenSSL glue layer? If the latter, then you either |
| 12 |
> build it to only use one, or you're going to hit symbol collisions |
| 13 |
> which are no fun to debug. |
| 14 |
|
| 15 |
Pure GnuTLS. |
| 16 |
|
| 17 |
> In general, as much as I like to allow alternatives, I'd suggest you |
| 18 |
> to pick a stand, and since OpenSSL is the lowest common denominator, |
| 19 |
> I'd suggest you pick that one. But for sure there will be people |
| 20 |
> complaining about licensing… |
| 21 |
|
| 22 |
Well, I thought about having 'ssl' to enable SSL support through |
| 23 |
OpenSSL and 'gnutls' to enable GnuTLS for the plugins supporting it. |
| 24 |
Then, logically, 'openssl' flag would be useful no more but wouldn't |
| 25 |
that imply exceeding the meaning of the 'ssl' flag? |
| 26 |
|
| 27 |
> How feasible would be to get upstream to implement GnuTLS support on |
| 28 |
> the remaining plugins? |
| 29 |
|
| 30 |
For the IRC plugin, it's pretty possible. For the sim plugin, I think |
| 31 |
it would be much harder. |
| 32 |
|
| 33 |
-- |
| 34 |
Best regards, |
| 35 |
Michał Górny |
Archives