ldnsutils emits wrong sha256 hashes

Subscribed Simon who added the openssl3 delta, he might have more context from having worked on so many of these changes.

Most likely change:
"2020-08-24 Use EVP_sha256 instead of HMAC_Update (for openssl-3.0.0)"

From
https://github.com/NLnetLabs/ldns/commit/12ab6f7a408cd99e9b43b7db86724c2ee66bc36e

That is the latest ssl3 toleration they have upstream (merged in 1.8.0, no updates in 1.8.1), but it seems something in there is wrong.

I'll try from git 1.8.1 and our version tomorrow and start looking for a fix from there.

Build instructions:

git clean -xdf
git checkout .
git submodule update --init
libtoolize -ci
autoreconf -fi
./configure --disable-rpath --with-examples --with-drill --enable-ed25519 --disable-ldns-config --build=x86_64-linux-gnu --prefix=/usr --includedir=/usr/include --mandir=/usr/share/man --infodir=/usr/share/info --sysconfdir=/etc --localstatedir=/var --disable-option-checking --disable-silent-rules --libdir=/usr//lib/x86_64-linux-gnu --runstatedir=/run --disable-maintainer-mode --disable-dependency-tracking
make
./examples/ldns-key2ds -n -2 ~/root.key

Various builds later (git = from git as above; pkg = re-build the pkg as-is):

git 1.7.1@i - bad result
git 1.7.1@j - ftbfs openssl
pkg 1.7.1@i - bad result
pkg 1.7.1@j - bad result
git 1.8.1@j - good result

Insight:
- 1.7.1 in Impish (e.g. on rebuild) is affected by the same issue
  - old in-archive builld is from hirsute 19 Nov 2020
- Something in 1.8.1 makes this right in jammy
- openssl3 breakage blocks most free bisecting

git 1.8.1@i - good result
git 1.8.0@j - good result

Insight:
- whatever is in 1.8.x fixes impish as well
- 1.8.0 is already good
- we might be able to bisect on Impish (no openssl3 block there)

Bisect new tag:1.8.0 <-> old tag:release-1.7.1

Identified:
- https://github.com/NLnetLabs/ldns/issues/131
- https://github.com/NLnetLabs/ldns/commit/4d2057f0b5220487882be1b19c302833b84cffe3

git 1.7.1@i + cherry pick - good result
git 1.8.1@j - revert fix - bad result

Insight:
- it is actually a gcc-11 issue of ldns
- fix can be backported and fixes the issue
- fixed in 1.8.0 and later

And @SSL3-patches, I beg your pardon - it was GCC11 after all :-)

Uploaded to Jammy, once in we can re-check dns-root-data and if all is fine we can consider if/how/when to SRU this.

We do only want to hold it back in impish, jammy we want to complete.
Updating the tag.

This bug was fixed in the package ldns - 1.7.1-2ubuntu4

---------------
ldns (1.7.1-2ubuntu4) jammy; urgency=medium

  * d/p/lp-1966237-Fix-131-Compile-with-fno-strict-aliasing.patch: fix
    wrong results in sha256 (LP: #1966237)

 -- Christian Ehrhardt <email address hidden> Fri, 25 Mar 2022 10:10:41 +0100

Uploaded the impish variant for SRU consideration

Since this is a fragile bug in the sense that the wrong build time option will silently result in a built binary that has wrong behaviour, _and_ the Test Plan is straightforward and (I think?) doesn't need an Internet connection or anything like that, then have you considered a dep8 test to make it less fragile? That would help to ensure that the bug remains fixed, including in the staged SRU case where the manual verification is expected to take place only once long before any other change, and there may be other changes in the meantime that we can't predict right now.

Ideally that'd go into an upstream test suite too.

I finished my SRU review and this is an SRU +1 regardless though, for the upload currently in Impish unapproved. I'm happy to accept immediately if you prefer. But I'll wait for your answer.

There actually is an autopkgtest exercising this already, as part of dns-root-data - this is how it was found. The problem is that this test isn't fired when ldns itself is updated :-/

I'd not want to block the SRU on this Robie.
But I'd be ok to file a request upstream to please add it to their build time tests - that will help down the road.

Ah OK. Great!

Hello Christian, or anyone else affected,

Accepted ldns into impish-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/ldns/1.7.1-2ubuntu0.1 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, what testing has been performed on the package and change the tag from verification-needed-impish to verification-done-impish. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-impish. In either case, without details of your testing we will not be able to proceed.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance for helping!

N.B. The updated package will be released to -updates after the bug(s) fixed by this package have been verified and the package has been in -proposed for a minimum of 7 days.

Request to add the test to the upstream build time test filed here:
https://github.com/NLnetLabs/ldns/issues/169

Upgraded and tested from impish proposed

root@i:~# dpkg -l ldnsutils
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name Version Architecture Description
+++-==============-================-============-=================================
ii ldnsutils 1.7.1-2ubuntu0.1 amd64 ldns library for DNS programming
root@i:~# /usr/bin/ldns-key2ds -n -2 root.key
. 86400 IN DS 20326 8 2 e06d44b80b8f1d39a95c0b0d7c65d08458e880409bbc683457104237c7f8ec8d

This is all good now, marking it verified (but it will stay there due to block proposed as intended)

impish has gone EOL without any further updates to ldns, therefore I am removing this package from -proposed and closing this bug wontfix as part of the EOL process.