changelog
- Fri, 16 Jun 2017 21:31:41 -0300
- by dx <dx@dxzone.com.ar> [Fri, 16 Jun 2017 21:31:41 -0300] rev 38373
- ssl-nss: Use default NSS ciphersuites/TLS versions, fixes TLS 1.3 issues
Recent NSS versions (3.27, 3.29) added TLS 1.3 support without enabling it in
the default configuration. But, for historical reasons, libpurple always
enables the latest TLS version, sets custom ciphersuite lists and disables all
the defaults, including ciphersuites needed for TLS 1.3 to work. This means
that connections to servers that support TLS 1.3 (for example, anything behind
cloudflare) always fail with "SSL Handshake Failed".
The solution is to just not do any of that. NSS has decent defaults, they
regularly update them and their devs will always know better than us.
Fixes #17217
The rest of the commit log is about those historical reasons.
The main user of NSS is firefox, which keeps its own ciphersuite and TLS
version preferences. In the past there were periods of time where firefox was
ahead of the NSS defaults, which caused connection issues or eyebrow-raising
ciphersuite choices. So libpurple tried to copy those prefs. I'm being told
by the NSS devs that nowadays they do a better job at keeping up.
The referenced issues in the deleted code are:
- Trac #1435 (2007), some connection issues due to disabled ciphers.
Probably NSS 3.11 or 3.12. So old it's not relevant, but interesting anyway.
The fix (hg 32a4cf358f9c) was enabling things that look like bad choices
nowadays, but the NSS defaults weren't better. Dark times. It looks like it was
effective to solve connection issues. Newer NSS versions definitely fixed this,
mostly with 3.14 (2012)
- Trac #15909 (2014), TLS 1.1 and 1.2 supported but not enabled.
NSS 3.14 (2012) introduced TLS 1.1; NSS 3.15.1 (2013) introduced TLS 1.2.
It wasn't until NSS 3.18 (2015) that they were enabled by default. The fix was
hg f4e63e354f45. This isn't needed anymore.
- Trac #16262 (2014), "Enabled ciphers in NSS unnecessarily limited"
Someone messed with ciphersuites in ejabberd and broke things. News at 11.
The ticket says "we don't have ciphers that support forward security" ignoring
that the DHE ones have that.
This was NSS 3.17 (2014). The fix (hg f26d96f03176) took the ciphersuite lists
from firefox to enable ECDHE and disable the defaults. ECDHE ciphersuites were
enabled by NSS 3.21 (2015).
- Trac #15862 (2014), "Disable Export ciphers and DES in SSL"
Windows pidgin 2.10.7 (2013) bundled NSS 3.13.6 (2012). Those were disabled by
NSS 3.14 (2012). Pidgin 2.10.8 (2014) updated to NSS 3.15.4 (2014).
---
This means that old NSS versions with bad defaults will use those bad defaults.
The earliest version in current LTS distros is 3.26, while our windows builds
have the oldest version, 3.24. These versions aren't affected by any of the
issues above.
- Fri, 16 Jun 2017 23:43:30 +0000
- by Gary Kramlich <grim@reaperworld.com> [Fri, 16 Jun 2017 23:43:30 +0000] rev 38372
- Merged in dequisdequis/pidgin/release-2.x.y (pull request #213)
purple_markup_unescape_entity: Fix handling of hexadecimal html entities
Approved-by: Eion Robb <eionrobb@gmail.com>
Approved-by: Gary Kramlich <grim@reaperworld.com>
Approved-by: Mike Ruprecht <cmaiku@gmail.com>
- Wed, 14 Jun 2017 16:57:48 -0300
- by dx <dx@dxzone.com.ar> [Wed, 14 Jun 2017 16:57:48 -0300] rev 38371
- purple_markup_unescape_entity: Fix handling of hexadecimal html entities
Somehow we were under the impression that isxdigit means hexadecimal digit and
the letter 'x' too.
Fixes #17177
- Fri, 02 Jun 2017 15:53:05 -0500
- by Mike Ruprecht <cmaiku@gmail.com> [Fri, 02 Jun 2017 15:53:05 -0500] rev 38370
- util: Remove two unused variables from purple_markup_unescape_entity()
- Fri, 16 Jun 2017 23:40:38 +0000
- by Gary Kramlich <grim@reaperworld.com> [Fri, 16 Jun 2017 23:40:38 +0000] rev 38369
- Merged in CMaiku/pidgin (pull request #215)
libpurple/xfer.c: Silence warnings in purple_xfer_set_thumbnail()
Approved-by: Eion Robb <eionrobb@gmail.com>
Approved-by: Elliott Sales de Andrade <quantum.analyst@gmail.com>
Approved-by: Gary Kramlich <grim@reaperworld.com>
- Thu, 15 Jun 2017 10:46:29 -0500
- by Mike Ruprecht <cmaiku@gmail.com> [Thu, 15 Jun 2017 10:46:29 -0500] rev 38368
- libpurple/xfer.c: Silence warnings in purple_xfer_set_thumbnail()
This patch fixes a mixed declarations and code warning and a discards
'const' qualifier from pointer target type warning:
xfer.c:1927:2: warning: ISO C90 forbids mixed declarations and code [-Wdeclaration-after-statement]
gpointer *old_thumbnail_data = priv->thumbnail_data;
xfer.c:1942:9: warning: passing argument 1 of ‘g_free’ discards ‘const’ qualifier from pointer target type [-Wdiscarded-qualifiers]
g_free(old_mimetype);
It also changes the old_thumbnail_data variable to match the type of
thumbnail_data in the priv structure.
- Fri, 16 Jun 2017 23:39:19 +0000
- by Gary Kramlich <grim@reaperworld.com> [Fri, 16 Jun 2017 23:39:19 +0000] rev 38367
- Merged in CMaiku/pidgin (pull request #200)
Use generic marshaller for GObject signals
Approved-by: Gary Kramlich <grim@reaperworld.com>
Approved-by: Eion Robb <eionrobb@gmail.com>
- Thu, 01 Jun 2017 21:31:43 -0500
- by Mike Ruprecht <cmaiku@gmail.com> [Thu, 01 Jun 2017 21:31:43 -0500] rev 38366
- gnt: Use default marshaller for GObject signals
Since 2.30 it's been possible to use a default c_marshaller by
passing NULL to g_signal_new(). It has since become the recommended
way of creating signals.
https://developer.gnome.org/gobject/stable/howto-signals.html
This patch ports libgnt to use this method instead of generating its
own marshallers with glib-genmarshal.
- Thu, 01 Jun 2017 21:35:39 -0500
- by Mike Ruprecht <cmaiku@gmail.com> [Thu, 01 Jun 2017 21:35:39 -0500] rev 38365
- libpurple: Use default marshaller for GObject signals
Since 2.30 it's been possible to use a default c_marshaller by
passing NULL to g_signal_new(). It has since become the recommended
way of creating signals.
https://developer.gnome.org/gobject/stable/howto-signals.html
This patch ports libpurple to use this method instead of generating
its own marshallers with glib-genmarshal.
- Sun, 04 Jun 2017 22:05:28 -0500
- by Mike Ruprecht <cmaiku@gmail.com> [Sun, 04 Jun 2017 22:05:28 -0500] rev 38364
- facebook: Use generic marshaller for GObject signals
Since 2.30 it's been possible to use a default c_marshaller by
passing NULL to g_signal_new(). It has since become the recommended
way of creating signals.
https://developer.gnome.org/gobject/stable/howto-signals.html
This patch ports the Facebook prpl to use this method instead
of generating its own marshallers with glib-genmarshal.
