** Description changed:
+ [Impact]
+
+ * When ldns is compiled with gcc11 without a fix for
+ strict-aliasing it will silently emit wrong sha256 hashes
+
+ * This affected Jammy where it was build with GCC11 already
+ and a fix was uploaded there.
+
+ * If rebuilt as-is today in Impish it would expose that bad
+ behavior. But the build of today is still from hirsute with GCC10.
+ Therefore we want to avoid this from ever becoming a problem,
+ but at the same time have no reason to push an update all
+ the way through.
+ The intention is to get this into impish-proposed and stay there
+ in case any later fix/security-update comes by it will not
+ trigger this problem.
+
+ [Test Plan]
+
+
+ $ cat > root.key << EOF
+ . 86400 IN DNSKEY 257 3 8
AwEAAaz/tAm8yTn4Mfeh5eyI96WSVexTBAvkMgJzkKTOiW1vkIbzxeF3+/4RgWOq7HrxRixHlFlExOLAJr5emLvN7SWXgnLh4+B5xQlNVz8Og8kvArMtNROxVQuCaSnIDdD5LKyWbRd2n9WGe2R8PzgCmr3EgVLrjyBxWezF0jLHwVN8efS3rCj/EWgvIWgb9tarpVUDK/b58Da+sqqls3eNbuv7pr+eoZG+SrDK6nWeL3c6H5Apxz7LjVc1uTIdsIXxuOLYA4/ilBmSVIzuDWfdRUfhHdY6+cn8HFRm+2hM8AnXGXws9555KrUB5qihylGa8subX2Nn6UwNR1AkUTV74bU=
;{id = 20326 (ksk), size = 2048b} ;;state=2 [ VALID ]
+ EOF
+
+ $ ldns-key2ds -n -2 root.key
+ . 86400 IN DS 20326 8 2
+
+ wrong result:
+ 0ae721f59a19244008217c3d2a646183acef2f17cf4c30929a3f29d09311c05e
+ correct result:
+ e06d44b80b8f1d39a95c0b0d7c65d08458e880409bbc683457104237c7f8ec8d
+
+
+ [Where problems could occur]
+
+ * If there is another - not yet discovered - issue with GCC11 it would
+ pick this one up; But it would do so as well without this fix and
+ with it we prevent at least one issue.
+
+ * If there was someone building ldns from package source relying on
+ strict-aliasing for anything this will now be disabled - but
+ intentionally, so IMHO ok.
+
+ [Other Info]
+
+ * As I mentioned above, this is not meant to migrate to -release,
+ we want it in -proposed to avoid a latter issue.
+
+
+ ---- original bug report ----
+
+
Hi,
originally this started by a finding of an FTFBS issue of dns-root-data [1]
as reported in the most recent archive rebuild [2]
But comparing those I've found that it is actually ldns that is broken,
as it seems most likely by openssl3.0 changes.
Separating this from dns-root-data, you can:
$ cat > root.key << EOF
. 86400 IN DNSKEY 257 3 8
AwEAAaz/tAm8yTn4Mfeh5eyI96WSVexTBAvkMgJzkKTOiW1vkIbzxeF3+/4RgWOq7HrxRixHlFlExOLAJr5emLvN7SWXgnLh4+B5xQlNVz8Og8kvArMtNROxVQuCaSnIDdD5LKyWbRd2n9WGe2R8PzgCmr3EgVLrjyBxWezF0jLHwVN8efS3rCj/EWgvIWgb9tarpVUDK/b58Da+sqqls3eNbuv7pr+eoZG+SrDK6nWeL3c6H5Apxz7LjVc1uTIdsIXxuOLYA4/ilBmSVIzuDWfdRUfhHdY6+cn8HFRm+2hM8AnXGXws9555KrUB5qihylGa8subX2Nn6UwNR1AkUTV74bU=
;{id = 20326 (ksk), size = 2048b} ;;state=2 [ VALID ]
EOF
$ ldns-key2ds -n -2 root.key
. 86400 IN DS 20326 8 2
0ae721f59a19244008217c3d2a646183acef2f17cf4c30929a3f29d09311c05e
The problem here is that this is the wrong hash.
The very same file used to emit:
. 86400 IN DS 20326 8 2
e06d44b80b8f1d39a95c0b0d7c65d08458e880409bbc683457104237c7f8ec8d
And on Impish it still does:
- ldnsutils | 1.7.1-2build1 | impish/universe | amd64, arm64,
armhf, ppc64el, riscv64, s390x
- ldnsutils | 1.7.1-2ubuntu3 | jammy/universe | amd64, arm64,
armhf, ppc64el, riscv64, s390x
+ ldnsutils | 1.7.1-2build1 | impish/universe | amd64, arm64,
armhf, ppc64el, riscv64, s390x
+ ldnsutils | 1.7.1-2ubuntu3 | jammy/universe | amd64, arm64,
armhf, ppc64el, riscv64, s390x
The difference between the two builds related to this seem to be the
openssl3.0 changes.
I say it is sha256 explicitly as that is what "-2" selects.
If I run with any of the other hashes jammy/impish still agree which tells me
that the rest of the process is still good.
- -1 Use SHA1 as the hash function.
- -2 Use SHA256 as the hash function
- -4 Use SHA384 as the hash function
+ -1 Use SHA1 as the hash function.
+ -2 Use SHA256 as the hash function
+ -4 Use SHA384 as the hash function
root@j:~# /usr/bin/ldns-key2ds -n -1 root.key
. 86400 IN DS 20326 8 1
ae1ea5b974d4c858b740bd03e3ced7ebfcbd1724
root@j:~# /usr/bin/ldns-key2ds -n -4 root.key
. 86400 IN DS 20326 8 4
538f47ba9bb88908e1dc335d6dfd51ca66b4d824192e6e6e210ae8cc18ece46a0f62b9f0d2f88dfc87d4bb8b8aed21cb
root@i:~# /usr/bin/ldns-key2ds -n -1 root.key
. 86400 IN DS 20326 8 1
ae1ea5b974d4c858b740bd03e3ced7ebfcbd1724
root@i:~# /usr/bin/ldns-key2ds -n -4 root.key
. 86400 IN DS 20326 8 4
538f47ba9bb88908e1dc335d6dfd51ca66b4d824192e6e6e210ae8cc18ece46a0f62b9f0d2f88dfc87d4bb8b8aed21cb
The build compares this to a root-anchors.xml from
http://data.iana.org/root-anchors/root-anchors.xml which also refers to
"E06D44B80B8F1D39A95C0B0D7C65D08458E880409BBC683457104237C7F8EC8D" so
I'm pretty sure our new build of ldns is the bad one here.
[1]:
https://people.canonical.com/~ginggs/ftbfs-report/test-rebuild-20220317-jammy-jammy.html#ubuntu-server-team
[2]:
https://launchpadlibrarian.net/591984954/buildlog_ubuntu-jammy-amd64.dns-root-data_2021011101_BUILDING.txt.gz
** Changed in: ldns (Ubuntu Impish)
Status: Confirmed => In Progress
** Changed in: ldns (Ubuntu Impish)
Assignee: (unassigned) => Christian Ehrhardt (paelzer)
** Description changed:
[Impact]
- * When ldns is compiled with gcc11 without a fix for
- strict-aliasing it will silently emit wrong sha256 hashes
+ * When ldns is compiled with gcc11 without a fix for
+ strict-aliasing it will silently emit wrong sha256 hashes
- * This affected Jammy where it was build with GCC11 already
- and a fix was uploaded there.
+ * This affected Jammy where it was build with GCC11 already
+ and a fix was uploaded there.
- * If rebuilt as-is today in Impish it would expose that bad
- behavior. But the build of today is still from hirsute with GCC10.
- Therefore we want to avoid this from ever becoming a problem,
- but at the same time have no reason to push an update all
- the way through.
- The intention is to get this into impish-proposed and stay there
- in case any later fix/security-update comes by it will not
- trigger this problem.
+ * If rebuilt as-is today in Impish it would expose that bad
+ behavior. But the build of today is still from hirsute with GCC10.
+ Therefore we want to avoid this from ever becoming a problem,
+ but at the same time have no reason to push an update all
+ the way through.
+ The intention is to get this into impish-proposed and stay there
+ in case any later fix/security-update comes by it will not
+ trigger this problem.
[Test Plan]
-
$ cat > root.key << EOF
. 86400 IN DNSKEY 257 3 8
AwEAAaz/tAm8yTn4Mfeh5eyI96WSVexTBAvkMgJzkKTOiW1vkIbzxeF3+/4RgWOq7HrxRixHlFlExOLAJr5emLvN7SWXgnLh4+B5xQlNVz8Og8kvArMtNROxVQuCaSnIDdD5LKyWbRd2n9WGe2R8PzgCmr3EgVLrjyBxWezF0jLHwVN8efS3rCj/EWgvIWgb9tarpVUDK/b58Da+sqqls3eNbuv7pr+eoZG+SrDK6nWeL3c6H5Apxz7LjVc1uTIdsIXxuOLYA4/ilBmSVIzuDWfdRUfhHdY6+cn8HFRm+2hM8AnXGXws9555KrUB5qihylGa8subX2Nn6UwNR1AkUTV74bU=
;{id = 20326 (ksk), size = 2048b} ;;state=2 [ VALID ]
EOF
$ ldns-key2ds -n -2 root.key
- . 86400 IN DS 20326 8 2
+ . 86400 IN DS 20326 8 2
wrong result:
0ae721f59a19244008217c3d2a646183acef2f17cf4c30929a3f29d09311c05e
correct result:
e06d44b80b8f1d39a95c0b0d7c65d08458e880409bbc683457104237c7f8ec8d
+ Note: To avoid confusion - once more to be clear - the ldns in impish as
+ of today is ok as it was built with older GCC, to see the bad-behavior
+ you'd need to rebuild it as-is.
[Where problems could occur]
- * If there is another - not yet discovered - issue with GCC11 it would
- pick this one up; But it would do so as well without this fix and
- with it we prevent at least one issue.
+ * If there is another - not yet discovered - issue with GCC11 it would
+ pick this one up; But it would do so as well without this fix and
+ with it we prevent at least one issue.
- * If there was someone building ldns from package source relying on
- strict-aliasing for anything this will now be disabled - but
- intentionally, so IMHO ok.
+ * If there was someone building ldns from package source relying on
+ strict-aliasing for anything this will now be disabled - but
+ intentionally, so IMHO ok.
[Other Info]
-
- * As I mentioned above, this is not meant to migrate to -release,
- we want it in -proposed to avoid a latter issue.
+ * As I mentioned above, this is not meant to migrate to -release,
+ we want it in -proposed to avoid a latter issue.
---- original bug report ----
-
Hi,
originally this started by a finding of an FTFBS issue of dns-root-data [1]
as reported in the most recent archive rebuild [2]
But comparing those I've found that it is actually ldns that is broken,
as it seems most likely by openssl3.0 changes.
Separating this from dns-root-data, you can:
$ cat > root.key << EOF
. 86400 IN DNSKEY 257 3 8
AwEAAaz/tAm8yTn4Mfeh5eyI96WSVexTBAvkMgJzkKTOiW1vkIbzxeF3+/4RgWOq7HrxRixHlFlExOLAJr5emLvN7SWXgnLh4+B5xQlNVz8Og8kvArMtNROxVQuCaSnIDdD5LKyWbRd2n9WGe2R8PzgCmr3EgVLrjyBxWezF0jLHwVN8efS3rCj/EWgvIWgb9tarpVUDK/b58Da+sqqls3eNbuv7pr+eoZG+SrDK6nWeL3c6H5Apxz7LjVc1uTIdsIXxuOLYA4/ilBmSVIzuDWfdRUfhHdY6+cn8HFRm+2hM8AnXGXws9555KrUB5qihylGa8subX2Nn6UwNR1AkUTV74bU=
;{id = 20326 (ksk), size = 2048b} ;;state=2 [ VALID ]
EOF
$ ldns-key2ds -n -2 root.key
. 86400 IN DS 20326 8 2
0ae721f59a19244008217c3d2a646183acef2f17cf4c30929a3f29d09311c05e
The problem here is that this is the wrong hash.
The very same file used to emit:
. 86400 IN DS 20326 8 2
e06d44b80b8f1d39a95c0b0d7c65d08458e880409bbc683457104237c7f8ec8d
And on Impish it still does:
ldnsutils | 1.7.1-2build1 | impish/universe | amd64, arm64,
armhf, ppc64el, riscv64, s390x
ldnsutils | 1.7.1-2ubuntu3 | jammy/universe | amd64, arm64,
armhf, ppc64el, riscv64, s390x
The difference between the two builds related to this seem to be the
openssl3.0 changes.
I say it is sha256 explicitly as that is what "-2" selects.
If I run with any of the other hashes jammy/impish still agree which tells me
that the rest of the process is still good.
-1 Use SHA1 as the hash function.
-2 Use SHA256 as the hash function
-4 Use SHA384 as the hash function
root@j:~# /usr/bin/ldns-key2ds -n -1 root.key
. 86400 IN DS 20326 8 1
ae1ea5b974d4c858b740bd03e3ced7ebfcbd1724
root@j:~# /usr/bin/ldns-key2ds -n -4 root.key
. 86400 IN DS 20326 8 4
538f47ba9bb88908e1dc335d6dfd51ca66b4d824192e6e6e210ae8cc18ece46a0f62b9f0d2f88dfc87d4bb8b8aed21cb
root@i:~# /usr/bin/ldns-key2ds -n -1 root.key
. 86400 IN DS 20326 8 1
ae1ea5b974d4c858b740bd03e3ced7ebfcbd1724
root@i:~# /usr/bin/ldns-key2ds -n -4 root.key
. 86400 IN DS 20326 8 4
538f47ba9bb88908e1dc335d6dfd51ca66b4d824192e6e6e210ae8cc18ece46a0f62b9f0d2f88dfc87d4bb8b8aed21cb
The build compares this to a root-anchors.xml from
http://data.iana.org/root-anchors/root-anchors.xml which also refers to
"E06D44B80B8F1D39A95C0B0D7C65D08458E880409BBC683457104237C7F8EC8D" so
I'm pretty sure our new build of ldns is the bad one here.
[1]:
https://people.canonical.com/~ginggs/ftbfs-report/test-rebuild-20220317-jammy-jammy.html#ubuntu-server-team
[2]:
https://launchpadlibrarian.net/591984954/buildlog_ubuntu-jammy-amd64.dns-root-data_2021011101_BUILDING.txt.gz
** Tags added: block-proposed
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1966237
Title:
ldnsutils emits wrong sha256 hashes
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/ldns/+bug/1966237/+subscriptions
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
