On 2020/06/05 00:21, Alex Free wrote: > > Sent: Friday, June 05, 2020 at 12:05 AM > > From: "Stuart Henderson" <s...@spacehopper.org> > > To: "Alex Free" <ale...@mail.com> > > Cc: "f.holop" <min...@obiit.org>, ports@openbsd.org > > Subject: Re: curl with libidn > > > > On 2020/06/04 22:39, Alex Free wrote: > > > > Sent: Thursday, June 04, 2020 at 4:53 PM > > > > From: "f.holop" <min...@obiit.org> > > > > To: ports@openbsd.org > > > > Subject: curl with libidn > > > > > > > > hi, > > > > > > > > atm curl is unable to open non ascii domains. > > > > is there a reason why it's not compiled with libidn? > > > > (same goes for lynx) > > > > > > > > -f > > > > -- > > > > > > > > > > > > > > If it compiles fine a flavor should be added to both. > > > > hahaha no. > > > > > > Your right it should just be a dependency to both.
If it's readded at all then it should just be a dependency (flavours in common libraries are a big problem). (it would be libidn2 not libidn, they are different codebases and supporting different IDNA specs). When IDN support was removed from the curl port before, upstream had hurriedly switched from libidn to libidn2 (despite at the time libidn being fairly well updated, and libidn2 having been mostly dead for about 5 years). IIRC this was to avoid problems with differences between the two IDNA specs (afaik both of which are still in use, though I have some recollection of at least some TLDs disallowing domains which conflict between the two? not sure..). Adding it would add more code to something that is quite a common dependency. Maybe it's useful enough to be worth it (being from a country with mostly 7-bit charset I don't get much of a vote in this ;) but along with the upside of support IDNs, there is a downside to pulling in (historically a bit buggy) code to all ports using the library. FWIW here are some of the more important libidn2 bugs. CVE-2019-12290 GNU libidn2 before 2.2.0 fails to perform the roundtrip checks specified in RFC3490 Section 4.2 when converting A-labels to U-labels. This makes it possible in some circumstances for one domain to impersonate another. By creating a malicious domain that matches a target domain except for the inclusion of certain punycoded Unicode characters (that would be discarded when converted first to a Unicode label and then back to an ASCII label), arbitrary domains can be impersonated. CVE-2019-18224 idn2_to_ascii_4i in lib/lookup.c in GNU libidn2 before 2.1.1 has a heap-based buffer overflow via a long domain string. CVE-2017-14062 Integer overflow in the decode_digit function in puny_decode.c in Libidn2 before 2.0.4 allows remote attackers to cause a denial of service or possibly have unspecified other impact. CVE-2017-14061 Integer overflow in the _isBidi function in bidi.c in Libidn2 before 2.0.4 allows remote attackers to cause a denial of service or possibly have unspecified other impact.
