> Sent: Friday, June 05, 2020 at 1:03 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/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. >
Why are flavors in common libraries a big problem putting aside the security issues and quality of code in this case?
