Bug 1449128

Summary:	ghostscript: switch to libidn2
Product:	[Fedora] Fedora	Reporter:	Nikos Mavrogiannopoulos <nmavrogi>
Component:	ghostscript	Assignee:	David Kaspar // Dee'Kej <deekej>
Status:	CLOSED NOTABUG	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	rawhide	CC:	deekej, twaugh, zdohnal
Target Milestone:	---
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2018-01-11 14:07:38 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:
Bug Blocks:	1439723

Description Nikos Mavrogiannopoulos 2017-05-09 09:27:20 UTC

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.

Comment 1 David Kaspar // Dee'Kej 2017-05-09 14:20:52 UTC

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

Comment 3 Jan Kurik 2017-08-15 07:18:18 UTC

This bug appears to have been reported against 'rawhide' during the Fedora 27 development cycle.
Changing version to '27'.

Comment 4 Nikos Mavrogiannopoulos 2017-11-23 08:27:19 UTC

(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?

Comment 5 David Kaspar // Dee'Kej 2017-11-23 09:53:36 UTC

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.

Comment 6 David Kaspar // Dee'Kej 2017-11-23 10:08:40 UTC

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.

Comment 7 David Kaspar // Dee'Kej 2017-11-23 10:27:04 UTC

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.

Comment 8 Nikos Mavrogiannopoulos 2017-11-23 11:57:30 UTC

(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.

Comment 9 David Kaspar // Dee'Kej 2017-11-23 12:11:56 UTC

(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.

Comment 10 David Kaspar // Dee'Kej 2018-01-11 14:07:38 UTC

> 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.