Description of problem: Internationalized domain names exist for quite some time (IDNA2003), although the protocols describing them have evolved in an incompatible way (IDNA2008). These incompatibilities will prevent applications written for IDNA2003 to access certain problematic domain names defined with IDNA2008, e.g., faß.de is translated to domain xn--fa-hia.de with IDNA2008, while in IDNA2003 it is translated to fass.de domain. That not only causes incompatibility problems, but may be used as an attack vector to redirect users to different web sites. The change is about deprecating libidn, which supports IDNA2003, and switch all applications using libidn, to libidn2 2.0.0, which supports IDNA2008. The switch should be transparent as the libidn2 library is API compatible. See instructions at: https://libidn.gitlab.io/libidn2/manual/libidn2.html#Converting-from-libidn This is part of the IDNA2008 change: https://fedoraproject.org/wiki/Changes/IDNA2008 If upstream is not aware of that change please involve them on the process.
Thank you for the information, Nikos. I will definitely let upstream know about this, if needed! :) And I will try to incoporate this change into bigger changes for ghostscript in F27. Best regards, Dee'Kej
This bug appears to have been reported against 'rawhide' during the Fedora 27 development cycle. Changing version to '27'.
(In reply to David Kaspar [Dee'Kej] from comment #1) > Thank you for the information, Nikos. > > I will definitely let upstream know about this, if needed! :) And I will try > to incoporate this change into bigger changes for ghostscript in F27. Hello David, Has this been addressed or forwarded to upstream?
Hello Nikos, I must admit I have forgotten completely about this BZ (I've left for a vacation few days after and then got buried under other stuff). :-/ I'm letting know upstream right now.
Okay, I have informed upstream about this via IRC, and created a BZ for it so everyone can track it there. Once they have a patch for this, I will backport it into F28. Until then, I expect to use the libidn though.
Update: According to upstream, they will try to get this change into ghostscript-9.23 (expected release date is approximately March 2018). As I said, in case they will have the fix for it sooner, I'll backport it to current ghostscript version so it is (hopefully) ready for F28. NOTE: AFAIK, upstream is using the libidn for support of UTF-8 passwords in e.g. locking the PDF files. I'm not aware of them using the libidn for Domain Names resolutions.
(In reply to David Kaspar [Dee'Kej] from comment #7) > Update: According to upstream, they will try to get this change into > ghostscript-9.23 (expected release date is approximately March 2018). > > As I said, in case they will have the fix for it sooner, I'll backport it to > current ghostscript version so it is (hopefully) ready for F28. > > NOTE: AFAIK, upstream is using the libidn for support of UTF-8 passwords in > e.g. locking the PDF files. I'm not aware of them using the libidn for > Domain Names resolutions. Aha, that's good to know. libidn provides stringprep functionality which is what they most probably rely on. In that case it may not be proper to switch to libidn2 as it (IDNA2008) doesn't use stringprep any more (new standards are different and called precis). If ghostscript doesn't use IDNA for DNS resolution it makes sense to close this bug as non applicable.
(In reply to Nikos Mavrogiannopoulos from comment #8) > Aha, that's good to know. libidn provides stringprep functionality which is > what they most probably rely on. In that case it may not be proper to switch > to libidn2 as it (IDNA2008) doesn't use stringprep any more (new standards > are different and called precis). If ghostscript doesn't use IDNA for DNS > resolution it makes sense to close this bug as non applicable. I will repost this info to Ghostscript upstream, so they can decide appropriately. :) I will get back to you once they decide.
> NOTE: AFAIK, upstream is using the libidn for support of UTF-8 passwords in > e.g. locking the PDF files. I'm not aware of them using the libidn for > Domain Names resolutions. I'm closing this BZ based on this. Upstream does not need to switch to libidn2 for now.