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.
This bug appears to have been reported against 'rawhide' during the Fedora 27 development cycle. Changing version to '27'.
Someone's sent a PR upstream for this, FWIW: https://github.com/achernya/hesiod/pull/13 doesn't seem to have been responded to.
(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 .....
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?
(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.
(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.
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.
(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.
Please re-open if plans to retire libidn come back. Otherwise we'll defer to upstream.