[gnutls-devel] GnuTLS 3.5.7 - any patches should I pick for Debian/stretch release?

[Tim Rühsen]

On Samstag, 28. Januar 2017 18:33:57 CET Andreas Metzler wrote:
> On 2017-01-28 Nikos Mavrogiannopoulos <n.mavrogiannopoulos at gmail.com> wrote:
> [...]
> 
> > A bit late, but some more bug fixes you may be interested to are:
> > 
> > IDNA2008 support: https://gitlab.com/gnutls/gnutls/merge_requests/240
> > While it is a feature, on certain occasions sticking to IDNA2003 can be
> > considered a vulnerability because of incompatibilities between the
> > mappings of UTF-8 DNS names to ascii format [0]. That is a quite large
> > bunch of patches, but in the long run  I think it is better to support
> > IDNA2008 rather than sticking to IDNA2003 which may cause potential
> > CVEs later.
> > 
> > A fix on AVX detection to allow gnutls run on certain virtual systems:
> > https://gitlab.com/gnutls/gnutls/commit/ef78a758cb899609d7eb4578017bc75227
> > 2cb423
> [...]
> 
> Thanks for the heads-up. Will definitily pull AVX fix. I will probably
> hold back with IDNA 2008. It is a too big change to try to squeeze in
> quickly.

Just want to mention that
- IDNA2008 is a bug + security fix to IDNA2003 (see https://curl.haxx.se/docs/
adv_20161102K.html)
- libcurl/curl now uses IDNA2008 + TR46 (libidn2 0.14+). Likely in testing 
already.
- libpsl uses IDNA2008 + TR46 (in testing)
- the german registry already uses IDNA2008
- the european registry already uses IDNA2008

AFAIK, firefox uses  IDNA2008, Chromium is still at 2003 (but this might change 
at will).

Moving to IDNA2008 cuts some ropes, some characters are disallowed that have 
been allowed before (not sure if any registry allowed those before at all).

While it is fine not pushing IDNA2008 in a hurry into the coming stable, you 
still have some good arguments on your side if you do ;-)

Regards, Tim
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part.
URL: </pipermail/attachments/20170201/1abe9bbe/attachment.sig>