TLS Libraries

Michael McConville mmcconville at mykolab.com
Sat Jun 20 19:31:50 EDT 2015


On Sun, Jun 21, 2015 at 09:54:17AM +1200, Eion Robb wrote:
> I can't remember what conclusion we got to though. Keeping the ssl
> pluginable is definitely an advantage.

One case in which this is true is allowing OpenSSL support. For example,
the OpenBSD port patches Pidgin to use OpenSSL:

	http://cvsweb.openbsd.org/cgi-bin/cvsweb/ports/net/pidgin/patches/

	https://developer.pidgin.im/wiki/FAQssl#WhycantIuseOpenSSLforSSLsupportinlibpurple

This might not be looked on kindly by the more GPL-friendly Pidgin devs,
but it's definitely useful.

> I'm not a fan of putting all the security eggs in one basket :)

In what sense do you mean this? Each individual Pidgin install (unless
the user is doing something particularly unique and weird) will only use
one TLS library, right? One's TLS library is largely predetermined, too,
because almost everyone uses either the Windows binary or a *nix
package.

In that case, we'd only have multiple baskets in terms of switching to
another TLS library in a later version. However, GnuTLS and NSS are both
big and widely used projects, so any security issue would be fixed long
before we could execute a mass basket-switch.

Let me know if I'm misunderstanding something.



More information about the Devel mailing list