Bug 1449130

Summary:	hesiod: switch to libidn2
Product:	[Fedora] Fedora	Reporter:	Nikos Mavrogiannopoulos <nmavrogi>
Component:	hesiod	Assignee:	Robbie Harwood <rharwood>
Status:	CLOSED UPSTREAM	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	rawhide	CC:	awilliam, ikent, nalin, pbrobinson
Target Milestone:	---	Keywords:	Tracking
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
URL:	https://github.com/achernya/hesiod/pull/13
Whiteboard:
Fixed In Version:		Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2018-10-11 18:04:43 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:29:33 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 Jan Kurik 2017-08-15 07:32:06 UTC

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

Comment 2 Adam Williamson 2018-05-18 22:18:19 UTC

Someone's sent a PR upstream for this, FWIW:

https://github.com/achernya/hesiod/pull/13

doesn't seem to have been responded to.

Comment 3 Ian Kent 2018-05-19 02:25:22 UTC

(In reply to Adam Williamson from comment #2)
> Someone's sent a PR upstream for this, FWIW:
> 
> https://github.com/achernya/hesiod/pull/13
> 
> doesn't seem to have been responded to.

That looks like it could be a problem for autofs.
I'm wondering if I should work out how to leave out hesiod
support rather than fail on dependencies at build .....

Comment 4 Adam Williamson 2018-05-19 06:59:12 UTC

Well, I rebuilt hesiod for the recent libidn soname bump in Rawhide and it built fine. So I don't know if there's an urgent problem here? Is someone planning to retire libidn imminently?

Comment 5 Ian Kent 2018-05-20 09:46:28 UTC

(In reply to Adam Williamson from comment #4)
> Well, I rebuilt hesiod for the recent libidn soname bump in Rawhide and it
> built fine. So I don't know if there's an urgent problem here? Is someone
> planning to retire libidn imminently?

The most recent build (last week) came back with:
DEBUG util.py:439:   Problem: package hesiod-devel-3.2.1-11.fc29.x86_64 requires libhesiod.so.0()(64bit), but none of the providers can be installed
DEBUG util.py:439:    - conflicting requests
DEBUG util.py:439:    - nothing provides libidn.so.11()(64bit) needed by hesiod-3.2.1-11.fc29.x86_64

so I thought it was because hesiod was still using libidn.

I'll try the build again and see if anything has changed.

Comment 6 Ian Kent 2018-05-20 10:09:04 UTC

(In reply to Ian Kent from comment #5)
> (In reply to Adam Williamson from comment #4)
> > Well, I rebuilt hesiod for the recent libidn soname bump in Rawhide and it
> > built fine. So I don't know if there's an urgent problem here? Is someone
> > planning to retire libidn imminently?
> 
> The most recent build (last week) came back with:
> DEBUG util.py:439:   Problem: package hesiod-devel-3.2.1-11.fc29.x86_64
> requires libhesiod.so.0()(64bit), but none of the providers can be installed
> DEBUG util.py:439:    - conflicting requests
> DEBUG util.py:439:    - nothing provides libidn.so.11()(64bit) needed by
> hesiod-3.2.1-11.fc29.x86_64
> 
> so I thought it was because hesiod was still using libidn.
> 
> I'll try the build again and see if anything has changed.

Oh well, whatever it was it's ok now, build went through fine.

Comment 7 Adam Williamson 2018-05-20 16:29:00 UTC

ian: that was just because hesiod hadn't yet been rebuilt for a libidn soname bump. I rebuilt hesiod on Friday, so the autofs build you did after I'd done that worked.

Comment 8 Ian Kent 2018-05-21 00:32:41 UTC

(In reply to Adam Williamson from comment #7)
> ian: that was just because hesiod hadn't yet been rebuilt for a libidn
> soname bump. I rebuilt hesiod on Friday, so the autofs build you did after
> I'd done that worked.

Right, I thought that was the case.
So there's no problem from my side then, thanks.

Comment 9 Robbie Harwood 2018-10-11 18:04:43 UTC

Please re-open if plans to retire libidn come back.  Otherwise we'll defer to upstream.