[gs-bugs] [Bug 698774] - Ghostscript - [configure] Add support for libidn2 and prefer it over libidn

[b***@artifex.com]

http://bugs.ghostscript.com/show_bug.cgi?id=698774

Bug ID: 698774
Summary: [configure] Add support for libidn2 and prefer it over
libidn
Product: Ghostscript
Version: 9.22
Hardware: PC
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P4
Component: Build Process
Assignee: ***@artifex.com
Reporter: ***@redhat.com
QA Contact: gs-***@ghostscript.com
Word Size: ---

Hello guys,

as we already discussed it on IRC, I'm creating this BZ so this issue is not
forgotten... :)

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

More info can be found on Fedora wiki:
--------------------------------------
https://fedoraproject.org/wiki/Changes/IDNA2008

Solution:
---------
Most likely the change to ./configure should be enough in a way that it looks
for 'libidn2' by default, and prefers it over the 'libidn' if both of them are
found.

Best regards,

-- Dee'Kej --

[b***@artifex.com]

http://bugs.ghostscript.com/show_bug.cgi?id=698774

--- Comment #1 from David Kaspar [Dee'Kej] <***@redhat.com> ---
Additional information from Nikos:

(In reply to David Kaspar [Dee'Kej] from comment #7)

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.

[b***@artifex.com]

http://bugs.ghostscript.com/show_bug.cgi?id=698774

--- Comment #2 from Chris Liddell (chrisl) <***@artifex.com> ---
So, does that mean we can just close this bug?

[b***@artifex.com]

http://bugs.ghostscript.com/show_bug.cgi?id=698774

--- Comment #3 from David Kaspar [Dee'Kej] <***@redhat.com> ---
To be honest, I really am not sure... :-/ Are you sure that you are using the
libidn only for UTF-8 passwords support?

[b***@artifex.com]

http://bugs.ghostscript.com/show_bug.cgi?id=698774

--- Comment #4 from Chris Liddell (chrisl) <***@artifex.com> ---
We do just use it to normalize password strings for PDFs.

My concern is if libidn is deprecated, it may fall into non-maintained mode. If
libidn2 supports the stringprep capability, we should use it.

[b***@artifex.com]

http://bugs.ghostscript.com/show_bug.cgi?id=698774

My concern is if libidn is deprecated, it may fall into non-maintained mode. If > libidn2 supports the stringprep capability, we should use it.

I'm affraid that the new stringprep functionality might be different, and
therefore passwords set for PDF with libidn wouldn't no longer work with
libidn2. In other words the old passwords for old documents wouldn't work with
Ghostscript using libidn2. This could make a lot of people unhappy.

I'll ask the coordinator of this change in Fedora if he can provide some more
info about this. For now, it might be better to keep this BZ opened.

[b***@artifex.com]

http://bugs.ghostscript.com/show_bug.cgi?id=698774

--- Comment #6 from Chris Liddell (chrisl) <***@artifex.com> ---
(In reply to David Kaspar [Dee'Kej] from comment #5)

Post by b***@artifex.com

My concern is if libidn is deprecated, it may fall into non-maintained mode. If > libidn2 supports the stringprep capability, we should use it.

I'm affraid that the new stringprep functionality might be different, and
therefore passwords set for PDF with libidn wouldn't no longer work with
libidn2. In other words the old passwords for old documents wouldn't work
with Ghostscript using libidn2. This could make a lot of people unhappy.

No, that's not quite the way we use it.

(simplistically) We read the password from the command line, and the password
from the PDF file, and then compare them. The problem is that (typically)
Unicode allows certain constructs to be represented in more than one way, so
simply taking the two Unicode strings and comparing them won't work reliably.
stringprep will "normalize" the two unicode strings into a form we can reliably
compare.

The results from stringprep should only ever be used internally, so it
shouldn't matter if the normalization from libidn2 differs from libidn.

[b***@artifex.com]

http://bugs.ghostscript.com/show_bug.cgi?id=698774

--- Comment #7 from Chris Liddell (chrisl) <***@artifex.com> ---
Reading the libidn2 docs, it not longer seems to include the stringprep() API.
As far as I can tell, all the libidn2 APIs (AFAICT) expect already normalized
UTF-8.

Which raises the question: do we need to consider a different UTF string
normalizing solution?