Re: possible idn decoding bug (at least as of 1.25)

[Simon Josefsson]

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