Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

libidn2 breaks CIDR notation #50

Closed
andreasstieger opened this issue Feb 27, 2017 · 7 comments
Closed

libidn2 breaks CIDR notation #50

andreasstieger opened this issue Feb 27, 2017 · 7 comments

Comments

@andreasstieger
Copy link
Contributor

andreasstieger commented Feb 27, 2017

There seems to be a problem when using libidn2 from #49 / 8ed6d73 with CIDR queries:

make clean; make all; ./whois -h whois.ripe.net 193.0.0.0/21
works

make clean; make all HAVE_LIBIDN=1; ./whois -h whois.ripe.net 193.0.0.0/21
works

make clean; make all HAVE_LIBIDN2=1; ./whois -h whois.ripe.net 193.0.0.0/21
returns:
%ERROR:101: no entries found

@rfc1036
Copy link
Owner

rfc1036 commented Feb 27, 2017

Looks like idn2_lookup_ul() really normalizes non-domains, so I will need to restructure the code to support libidn2, but this will take some time.
Cc @rockdaboot

@rockdaboot
Copy link

Not sure what the problem is. Could you give an example ? Maybe I can give you helping hand.

@rfc1036
Copy link
Owner

rfc1036 commented Feb 27, 2017

Just query something with a / in it, e.g.:

whois --verbose 193.0.0.0/21

You will see that the / will be removed.

@rockdaboot
Copy link

That is a TR46 preprocessing thing. And you are right, if something is a domain or not (e.g. IP or network address) currently isn't handled by libidn2. So the application has to decide.
But we (at libidn2) would discuss to check for standard non-domains in the API. Please open an issue at https://gitlab.com/jas/libidn2/issues with a reference to this issue here.

Just for the record, the described behavior can be reproduced by:

$ idn2 -T 193.0.0.0/21
193.0.0.021

@andreasstieger
Copy link
Contributor Author

So that do you think about #53? Tests fine for all my test cases.

@rockdaboot
Copy link

You got my 👍 (= looks good) 6 days ago.

@andreasstieger
Copy link
Contributor Author

So indeed with libidn2 2.0.3 the problems are gone:

make clean; make all HAVE_LIBIDN2=1
./whois -h whois.ripe.net 193.0.0.0/21
./whois 2001:67c:2178:8::1

So neither d6e33ff nor 1e6a7b3 are required to fix CIDR notation queries, and the fix is in libidn2. So I think this can be closed.

rfc1036 added a commit that referenced this issue Aug 22, 2017
libidn2 >= 2.0.3 must be used, or else it would silently remove
characters not valid in hostnames like "/" and "_".
For details see #50 .

For more information about IDNA2003 vs. IDNA2008 and TR46 see:
http://nmav.gnutls.org/2017/04/the-mess-with-internationalized-domain.html
http://unicode.org/faq/idn.html
https://fedoraproject.org/wiki/Changes/IDNA2008
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants