| 2022-03-24 14:56:14 |
Christian Ehrhardt |
bug |
|
|
added bug |
| 2022-03-24 14:56:24 |
Christian Ehrhardt |
bug |
|
|
added subscriber Simon Chopin |
| 2022-03-24 14:56:33 |
Christian Ehrhardt |
bug |
|
|
added subscriber Ubuntu Server |
| 2022-03-24 14:56:41 |
Christian Ehrhardt |
tags |
|
server-todo |
|
| 2022-03-24 14:56:46 |
Christian Ehrhardt |
ldns (Ubuntu): importance |
Undecided |
High |
|
| 2022-03-24 14:58:22 |
Simon Chopin |
tags |
server-todo |
server-todo transition-openssl3-jj |
|
| 2022-03-25 09:13:08 |
Launchpad Janitor |
merge proposal linked |
|
https://code.launchpad.net/~paelzer/ubuntu/+source/ldns/+git/ldns/+merge/417678 |
|
| 2022-03-25 09:14:02 |
Christian Ehrhardt |
bug watch added |
|
https://github.com/NLnetLabs/ldns/issues/131 |
|
| 2022-03-25 09:14:48 |
Christian Ehrhardt |
tags |
server-todo transition-openssl3-jj |
server-todo |
|
| 2022-03-25 09:17:09 |
Christian Ehrhardt |
nominated for series |
|
Ubuntu Impish |
|
| 2022-03-25 09:17:09 |
Christian Ehrhardt |
bug task added |
|
ldns (Ubuntu Impish) |
|
| 2022-03-25 09:17:09 |
Christian Ehrhardt |
nominated for series |
|
Ubuntu Jammy |
|
| 2022-03-25 09:17:09 |
Christian Ehrhardt |
bug task added |
|
ldns (Ubuntu Jammy) |
|
| 2022-03-25 09:17:14 |
Christian Ehrhardt |
ldns (Ubuntu Jammy): status |
New |
Confirmed |
|
| 2022-03-25 09:17:17 |
Christian Ehrhardt |
ldns (Ubuntu Jammy): status |
Confirmed |
In Progress |
|
| 2022-03-25 09:17:19 |
Christian Ehrhardt |
ldns (Ubuntu Impish): status |
New |
Confirmed |
|
| 2022-03-25 09:17:20 |
Christian Ehrhardt |
ldns (Ubuntu Impish): importance |
Undecided |
Medium |
|
| 2022-03-25 09:17:28 |
Christian Ehrhardt |
ldns (Ubuntu Jammy): assignee |
|
Christian Ehrhardt (paelzer) |
|
| 2022-03-28 06:03:48 |
Christian Ehrhardt |
description |
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 |
[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
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 |
|
| 2022-03-28 06:03:52 |
Christian Ehrhardt |
ldns (Ubuntu Impish): status |
Confirmed |
In Progress |
|
| 2022-03-28 06:03:55 |
Christian Ehrhardt |
ldns (Ubuntu Impish): assignee |
|
Christian Ehrhardt (paelzer) |
|
| 2022-03-28 06:04:58 |
Christian Ehrhardt |
description |
[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
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 |
[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
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 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
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 |
|
| 2022-03-28 06:05:10 |
Christian Ehrhardt |
tags |
server-todo |
block-proposed server-todo |
|
| 2022-03-28 06:05:26 |
Launchpad Janitor |
merge proposal linked |
|
https://code.launchpad.net/~paelzer/ubuntu/+source/ldns/+git/ldns/+merge/417721 |
|
| 2022-03-29 06:20:15 |
Christian Ehrhardt |
tags |
block-proposed server-todo |
block-proposed-impish server-todo |
|
| 2022-03-29 09:06:34 |
Launchpad Janitor |
ldns (Ubuntu Jammy): status |
In Progress |
Fix Released |
|
| 2022-04-06 13:31:21 |
Robie Basak |
bug |
|
|
added subscriber Robie Basak |
| 2022-04-06 14:43:02 |
Robie Basak |
ldns (Ubuntu Impish): status |
In Progress |
Fix Committed |
|
| 2022-04-06 14:43:03 |
Robie Basak |
bug |
|
|
added subscriber Ubuntu Stable Release Updates Team |
| 2022-04-06 14:43:04 |
Robie Basak |
bug |
|
|
added subscriber SRU Verification |
| 2022-04-06 14:43:06 |
Robie Basak |
tags |
block-proposed-impish server-todo |
block-proposed-impish server-todo verification-needed verification-needed-impish |
|
| 2022-04-07 07:47:22 |
Christian Ehrhardt |
bug watch added |
|
https://github.com/NLnetLabs/ldns/issues/169 |
|
| 2022-04-07 07:50:14 |
Christian Ehrhardt |
tags |
block-proposed-impish server-todo verification-needed verification-needed-impish |
block-proposed-impish server-todo verification-done verification-done-impish |
|
| 2022-04-20 15:14:07 |
Christian Ehrhardt |
tags |
block-proposed-impish server-todo verification-done verification-done-impish |
block-proposed-impish verification-done verification-done-impish |
|
| 2022-07-15 16:53:37 |
Steve Langasek |
ldns (Ubuntu Impish): status |
Fix Committed |
Won't Fix |
|
