[Pidgin] #15308: SSL support appears to have been written by a lobotomy victim

[Pidgin]

#15308: SSL support appears to have been written by a lobotomy victim
-------------------+--------------------------------------------------------
Reporter:  athena  |        Type:  defect   
  Status:  new     |   Component:  libpurple
 Version:  2.10.6  |    Keywords:           
-------------------+--------------------------------------------------------
 Allow me to direct your attention to the function ssl_auth_cert() in
 libpurple/plugins/ssl/ssl-nss.c:
 http://hg.pidgin.im/pidgin/main/file/52cc04429e2c/libpurple/plugins/ssl
 /ssl-nss.c#l160

 Note the rather ill-chosen preprocessor directives, making the use of SSL
 essentially worthless, as MITMing this crawling horror would be no more
 difficult than a plain, unencrypted TCP connection.

 Furthermore, I will note that many common builds of libpurple, including
 the Ubuntu package provided by the Pidgin team at https://launchpad.net
 /~pidgin-
 developers/+archive/ppa/+files/pidgin_2.10.6-0ubuntu1%2Bpidgin1.12.10.debian.tar.gz
 and the build of 2.10.6 in Debian sid, enable the ssl-nss plugin, but not
 the ssl-gnutls one.

 Not that it would help much, of course - see probe_ssl_plugins() of
 libpurple/plugins/ssl/ssl.c:

 http://hg.pidgin.im/pidgin/main/file/52cc04429e2c/libpurple/plugins/ssl/ssl.c#l33

 This is hard-coded to load whichever appears first in the global list of
 plugins returned from purple_plugins_get_all(), which is updated from
 purple_plugin_register() at plugin probe time:

 http://hg.pidgin.im/pidgin/main/file/52cc04429e2c/libpurple/plugin.c#l1595

 http://hg.pidgin.im/pidgin/main/file/52cc04429e2c/libpurple/plugin.c#l1484

 http://hg.pidgin.im/pidgin/main/file/52cc04429e2c/libpurple/plugin.h#l232

 http://hg.pidgin.im/pidgin/main/file/52cc04429e2c/libpurple/plugin.c#l300

 The function purple_plugin_probe(), in turn, can be called from either
 purple_plugins_probe(), or from purple_plugins_load_saved(), which merely
 loads the user's selection from a UI which does not expose any choice
 about the SSL plugins.  The ssl plugin would ultimately be determined by
 which is probed first from purple_plugins_probe, which calls g_dir_open()
 and invokes purple_plugin_probe() on the files returned by
 g_dir_read_name() in the order they are returned.h.

 Per glib documentation, the order of entries returned by g_dir_read_name()
 is indeterminate and system-dependent:

 http://developer.gnome.org/glib/2.29/glib-File-Utilities.html#g-dir-read-
 name

 Per latest glib source, g_open_dir() and g_dir_read_name() call opendir()
 and readdir(), respectively:

 http://git.gnome.org/browse/glib/tree/glib/gdir.c

 Thus, the order of plugin loading and thus whether or not a user with both
 SSL plugins built will bother checking any certificates will ultimately be
 determined by such factors as the order in which the plugin binaries were
 installed and the choice of filesystem.

 I strongly advise suggesting distributors prefer GnuTLS over NSS, then
 fixing NSS, then reconsidering your lack of OpenSSL support, and exposing
 a UI to let the user choose which SSL plugin to use when more than one is
 available.  Passing a licensing purity test is not worth this absurd
 Potemkin village security.

-- 
Ticket URL: <http://developer.pidgin.im/ticket/15308>
Pidgin <http://pidgin.im>
Pidgin