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.