[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: possible idn decoding bug (at least as of 1.25)
From: |
Simon Josefsson |
Subject: |
Re: possible idn decoding bug (at least as of 1.25) |
Date: |
Sat, 03 May 2014 22:30:44 +0200 |
User-agent: |
Gnus/5.130011 (Ma Gnus v0.11) Emacs/24.3 (gnu/linux) |
Jon Nelson <address@hidden> writes:
> I've found what I believe to be a bug in libidn (<= 1.25, didn't check
> more recent versions).
>
> The following IDNA-encoded domain, when run through idn, does not
> result in an error.
>
> xn--9k39ivpi18g4vn.cn
Strings that cannot be decoded are returned as-is. Quoting RFC 3490:
ToUnicode never fails. If any step fails, then the original input
sequence is returned immediately in that step.
Thus, I believe this is expected behaviour.
/Simon
> However, Python does complain:
>
> python -c "'xn--9k39ivpi18g4vn.cn'.decode('idna')"
>
> Traceback (most recent call last):
> File "<string>", line 1, in <module>
> File "/usr/lib64/python2.7/encodings/idna.py", line 193, in decode
> result.append(ToUnicode(label))
> File "/usr/lib64/python2.7/encodings/idna.py", line 131, in ToUnicode
> result = label1.decode("punycode")
> File "/usr/lib64/python2.7/encodings/punycode.py", line 208, in decode
> res = punycode_decode(input, errors)
> File "/usr/lib64/python2.7/encodings/punycode.py", line 195, in
> punycode_decode
> return insertion_sort(base, extended, errors)
> File "/usr/lib64/python2.7/encodings/punycode.py", line 177, in
> insertion_sort
> raise UnicodeError, ("Invalid character U+%x" % char)
> UnicodeError: Invalid character U+160bb4
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- Re: possible idn decoding bug (at least as of 1.25),
Simon Josefsson <=