ISC Open Source Projects issueshttps://gitlab.isc.org/groups/isc-projects/-/issues2022-09-15T13:09:56Zhttps://gitlab.isc.org/isc-projects/kea/-/issues/2405GSS-TSIG Broken response2022-09-15T13:09:56ZPeter DaviesGSS-TSIG Broken response GSS-TSIG Broken response
MS DNS servers seem to return a broken DDNS response, copying the entire
original request (including the TSIG RR) just setting the QR bit. The only
exception seems to be a response for a successful DDNS req... GSS-TSIG Broken response
MS DNS servers seem to return a broken DDNS response, copying the entire
original request (including the TSIG RR) just setting the QR bit. The only
exception seems to be a response for a successful DDNS request using TSIG, in
which case the TSIG RR of the response has a valid MAC for the response. In
our experience the broken responses can be sent when a DDNS prerequisite check
fails, authentication fails, or non-secure DDNS is allowed.
In the case of GSS-TSIG, the copied (broken) GSS token triggers the following
error:
INFO [kea-dhcp-ddns.gss-tsig-hooks/4678.139690935890624]
GSS_TSIG_VERIFY_FAILED GSS-TSIG verify failed: gss_verify_mic failed with
GSSAPI error:
Major = 'A token had an invalid Message Integrity Check (MIC)' (393216),
Minor = 'Packet was replayed in wrong direction' (100002).
it's not surprising since it's the token sent by Kea and the direction is
indeed wrong. I also suspect it's irrelevant to configuring or not configuring
a reverse mapping zone.
We might provide a way to disable integrity check on the response (usually DDNS
response is not that important) to work around this buggy behavior of MS
server. But that's probably considered to be too radical. (Relatively)
fortunately, these cases are usually just treated as an update failure anyway,
so probably we'll just need to live with the bug.
[RT #20795](https://support.isc.org/Ticket/Display.html?id=20795)kea2.3.1Peter DaviesPeter Davieshttps://gitlab.isc.org/isc-projects/kea/-/issues/2003host reservations and replicated databases2022-09-30T10:13:20ZPeter Davieshost reservations and replicated databaseshost reservations and replicated databases:
In order to increase availability would it be possible to configure Kea so that Host Reservation (HR) lookups could be directed to one or more read only database replicates.
Also that HR u...host reservations and replicated databases:
In order to increase availability would it be possible to configure Kea so that Host Reservation (HR) lookups could be directed to one or more read only database replicates.
Also that HR update commands in the Host Commands hooks libraries (host_cmd) can be configured to use a read/write database, or to be able to identify a read/write database from the set of "hosts-databases".
Maybe something like:
```
"hosts-databases": [
{
"type": "mysql",
"name": "Repicate-1",
"user-context": {
"use": "query",
"next": "Master"
},
...
},
"type": "mysql,
"name": "Repicate-2",
"user-context": {
"use": "query",
"next": "Master"
},
"type": "mysql,
"name": "Master",
"user-context": {
"use": "update",
"next": ""
},
...
}
],
```
[support#18800](https://support.isc.org/Ticket/Display.html?id=18800)kea2.3.1Wlodzimierz WencelWlodzimierz Wencelhttps://gitlab.isc.org/isc-projects/kea/-/issues/1955ERROR log messages don't get sent to configured output file at startup2023-07-17T13:58:24ZAndrei Pavelandrei@isc.orgERROR log messages don't get sent to configured output file at startupWhile having MySQL shut down on localhost, start kea-dhcp6 with:
```
{
"Dhcp6": {
"lease-database": {
"name": "keatest",
"password": "keatest",
"user": "keatest",
"type": "mysql"
},
"loggers": [
...While having MySQL shut down on localhost, start kea-dhcp6 with:
```
{
"Dhcp6": {
"lease-database": {
"name": "keatest",
"password": "keatest",
"user": "keatest",
"type": "mysql"
},
"loggers": [
{
"debuglevel": 0,
"name": "kea-dhcp6",
"output_options": [
{
"output": "/var/log/kea-dhcp6.log"
}
],
"severity": "INFO"
}
]
}
}
```
You'll see the following messages in the log file:
```
INFO HOSTS_BACKENDS_REGISTERED
INFO DHCP6_CONFIG_COMPLETE
INFO DHCPSRV_MYSQL_DB opening
```
But the following messages are only sent to standard output and standard error:
```
INFO DHCP6_STARTING
WARN DHCP6_DEVELOPMENT_VERSION
ERROR DHCP6_CONFIG_LOAD_FAIL
ERROR DHCP6_INIT_FAIL
```
The INFO message logs predate the ERROR message logs so it's not like the logger isn't properly initialized when ERROR messages are logged.
Anyway, the suggestions are:
* initialize the logger as early as possible, maybe in a separate first pass of the configuration
* send as many logs as possible to the configured output
This is affecting customers who run Kea as a systemd service. Most packages install a systemd service. They can't see the reason of the failure unless they look in /var/log/messages or syslog instead of the configured /var/log/kea-dhcp6.log.
[RT#18588](https://support.isc.org/Ticket/Display.html?id=18588)kea2.3.1Andrei Pavelandrei@isc.orgAndrei Pavelandrei@isc.orghttps://gitlab.isc.org/isc-projects/kea/-/issues/1654Leases-write command2023-07-17T13:58:24ZTomek MrugalskiLeases-write command There was an issue one customer experienced. He was using memfile and ran out of diskspace. Kea kept running, but the leases were only updated in memory and not written to disk.
Currently, there is no way to recover from this situation... There was an issue one customer experienced. He was using memfile and ran out of diskspace. Kea kept running, but the leases were only updated in memory and not written to disk.
Currently, there is no way to recover from this situation. The ``leases-write`` command would allow manually forcing writing all leases to disk.
For background problem that triggered this problem, see [support#17565](https://support.isc.org/Ticket/Display.html?id=17565).kea2.3.1Francis DupontFrancis Duponthttps://gitlab.isc.org/isc-projects/bind9/-/issues/3587Debugging named ACLs is hard2022-10-20T09:34:31ZMichał KępieńDebugging named ACLs is hardSee #3481 & #3482 for context.
There is much room for improvement in terms of making `named` more
verbose about which ACLs matched during query processing and which ones
did not. Better logging would help administrators understand and
...See #3481 & #3482 for context.
There is much room for improvement in terms of making `named` more
verbose about which ACLs matched during query processing and which ones
did not. Better logging would help administrators understand and
fine-tune ACLs.October 2022 (9.16.34, 9.16.34-S1, 9.18.8, 9.19.6)https://gitlab.isc.org/isc-projects/bind9/-/issues/3582CID 358309: Integer handling issues in tests/bench/siphash.c2022-10-05T14:07:47ZMichal NowakCID 358309: Integer handling issues in tests/bench/siphash.cisc-projects/bind9!6789 added the `siphash` benchmark. Coverity Scan reports a possible undefined behavior issue in it:
```
/tests/bench/siphash.c: 54 in main()
48 count++;
49 }
50
51 isc_time_now_hires(&finish);
...isc-projects/bind9!6789 added the `siphash` benchmark. Coverity Scan reports a possible undefined behavior issue in it:
```
/tests/bench/siphash.c: 54 in main()
48 count++;
49 }
50
51 isc_time_now_hires(&finish);
52
53 us = isc_time_microdiff(&finish, &start);
>>> CID 358309: Integer handling issues (DIVIDE_BY_ZERO)
>>> In expression "count * 1000UL / us", division by expression "us" which may be zero has undefined behavior.
54 printf("%f us wide-lower len %3zu, %7llu kh/s (%llx)\n",
55 (double)us / 1000000.0, len,
56 (unsigned long long)(count * 1000 / us),
57 (unsigned long long)sum);
58 }
59
```
@ondrej @fanf Can you please have a look?October 2022 (9.16.34, 9.16.34-S1, 9.18.8, 9.19.6)https://gitlab.isc.org/isc-projects/bind9/-/issues/3580CID 358310: Possible Control flow issues in lib/isc/resource.c2022-10-05T15:51:21ZMichal NowakCID 358310: Possible Control flow issues in lib/isc/resource.cAfter isc-projects/bind9!6788 (a fix for isc-projects/bind9#3549) Coverity Scan reports the following on `main`:
```
*** CID 358310: Possible Control flow issues (DEADCODE)
/lib/isc/resource.c: 118 in isc_resource_setlimit()
112 ...After isc-projects/bind9!6788 (a fix for isc-projects/bind9#3549) Coverity Scan reports the following on `main`:
```
*** CID 358310: Possible Control flow issues (DEADCODE)
/lib/isc/resource.c: 118 in isc_resource_setlimit()
112 * rlim_t, and whether rlim_t has a sign bit.
113 */
114 isc_resourcevalue_t rlim_max = UINT64_MAX;
115 size_t wider = sizeof(rlim_max) - sizeof(rlim_t);
116 bool sign_bit = (double)(rlim_t)-1 < 0;
117
>>> CID 358310: Possible Control flow issues (DEADCODE)
>>> Execution cannot reach the expression "1" inside this statement: "rlim_max >>= 8UL * wider + ...".
118 rlim_max >>= CHAR_BIT * wider + (sign_bit ? 1 : 0);
119 rlim_value = ISC_MIN(value, rlim_max);
120 }
121
122 rl.rlim_cur = rl.rlim_max = rlim_value;
123 unixresult = setrlimit(unixresource, &rl);
```
@fanf Can you have a look, please?October 2022 (9.16.34, 9.16.34-S1, 9.18.8, 9.19.6)Tony FinchTony Finchhttps://gitlab.isc.org/isc-projects/bind9/-/issues/3578Retain the possibility to use OpenSSL engines with OpenSSL 3.x2024-03-28T16:48:17ZMichał KępieńRetain the possibility to use OpenSSL engines with OpenSSL 3.xSee #2996 for context.
It would be useful to retain the possibility to use OpenSSL engines with
OpenSSL 3.x; it is possible to build against the latter in API
compatibility mode (`-DOPENSSL_API_COMPAT=10100`), so we should take
advantag...See #2996 for context.
It would be useful to retain the possibility to use OpenSSL engines with
OpenSSL 3.x; it is possible to build against the latter in API
compatibility mode (`-DOPENSSL_API_COMPAT=10100`), so we should take
advantage of that before a "native" OpenSSL 3.x provider gets
implemented.October 2022 (9.16.34, 9.16.34-S1, 9.18.8, 9.19.6)https://gitlab.isc.org/isc-projects/bind9/-/issues/3577reloads in ixfr system test happen too fast2022-10-06T09:28:53ZMark Andrewsreloads in ixfr system test happen too fastThe ixfr system test can fail because reloads happen too fast causing the reload of
zone files to be skipped as up to date.
```
I:ixfr:testing 'request-ixfr yes' option inheritance from view (7)
I:ixfr:ns3 server reload successful
I:ixf...The ixfr system test can fail because reloads happen too fast causing the reload of
zone files to be skipped as up to date.
```
I:ixfr:testing 'request-ixfr yes' option inheritance from view (7)
I:ixfr:ns3 server reload successful
I:ixfr:exceeded time limit waiting for literal 'got incremental response' in ns4/named.run
I:ixfr:failed
```
```
05-Oct-2022 16:18:18.158 received control channel command 'reload'
05-Oct-2022 16:18:18.254 received control channel command 'reload'
05-Oct-2022 16:18:18.350 received control channel command 'reload'
```October 2022 (9.16.34, 9.16.34-S1, 9.18.8, 9.19.6)https://gitlab.isc.org/isc-projects/bind9/-/issues/3575CID 357159 Double free in lib/dns/request.c2022-10-05T09:29:12ZMichal NowakCID 357159 Double free in lib/dns/request.cCoverity Scan reports on `v9_18`:
```
/lib/dns/request.c: 794 in dns_request_create()
788 /* connect failed, detach here */
789 req_detach(&(dns_request_t *){ request });
790
791 cleanup:
792 isc_task_detach(&(isc...Coverity Scan reports on `v9_18`:
```
/lib/dns/request.c: 794 in dns_request_create()
788 /* connect failed, detach here */
789 req_detach(&(dns_request_t *){ request });
790
791 cleanup:
792 isc_task_detach(&(isc_task_t *){ task });
793 /* final detach to shut down request */
>>> CID 357159: (USE_AFTER_FREE)
>>> Calling "req_detach" frees pointer "request" which has already been freed.
794 req_detach(&request);
795 req_log(ISC_LOG_DEBUG(3), "dns_request_create: failed %s",
796 isc_result_totext(result));
797 return (result);
798 }
799
```
This seems to come from 8f61d07918d083600404b230c7254dab72e5fd5f.October 2022 (9.16.34, 9.16.34-S1, 9.18.8, 9.19.6)Evan HuntEvan Hunthttps://gitlab.isc.org/isc-projects/bind9/-/issues/3572Sphinx 5.2 reports a warning for doc/arm/catz.inc.rst2022-10-05T12:11:57ZMichał KępieńSphinx 5.2 reports a warning for doc/arm/catz.inc.rstSphinx 5.2.2 reports the following warning when `make doc` is run for
current `main` and `v9_18`:
```
Running Sphinx v5.2.2
making output directory... done
building [mo]: all of 0 po files
building [html]: all source files
updating envi...Sphinx 5.2.2 reports the following warning when `make doc` is run for
current `main` and `v9_18`:
```
Running Sphinx v5.2.2
making output directory... done
building [mo]: all of 0 po files
building [html]: all source files
updating environment: [new config] 16 added, 0 changed, 0 removed
reading sources... [100%] reference
looking for now-outdated files... none found
pickling environment... done
checking consistency... done
preparing documents... done
writing output... [100%] reference
Warning, treated as error:
/tmp/bind9/doc/arm/catz.inc.rst:234:more than one target found for 'any' cross-reference 'allow-query': could be :std:ref:`allow-query` or :namedconf:ref:`namedconf-statement-allow-query`
make[2]: *** [Makefile:757: html-local] Error 2
```
The line being flagged above has been around for the past two months and
it worked fine with Sphinx 5.1.1, so I assume that it is some new check
in the most up-to-date Sphinx version that triggers this warning.October 2022 (9.16.34, 9.16.34-S1, 9.18.8, 9.19.6)Petr Špačekpspacek@isc.orgPetr Špačekpspacek@isc.orghttps://gitlab.isc.org/isc-projects/bind9/-/issues/3571ThreadSanitizer: data race /builds/isc-projects/bind9/lib/dns/nta.c:659:11 in...2022-10-06T10:14:25ZOndřej SurýThreadSanitizer: data race /builds/isc-projects/bind9/lib/dns/nta.c:659:11 in dns__nta_shutdown```
WARNING: ThreadSanitizer: data race (pid=4175)
Read of size 8 at 0x7b5c00000030 by thread T10:
#0 dns__nta_shutdown /builds/isc-projects/bind9/lib/dns/nta.c:659:11 (libdns-9.19.6-dev.so+0xcff1f) (BuildId: 99aa8075eafa451b920a93...```
WARNING: ThreadSanitizer: data race (pid=4175)
Read of size 8 at 0x7b5c00000030 by thread T10:
#0 dns__nta_shutdown /builds/isc-projects/bind9/lib/dns/nta.c:659:11 (libdns-9.19.6-dev.so+0xcff1f) (BuildId: 99aa8075eafa451b920a93883c4f94409e999aac)
#1 dns__nta_free /builds/isc-projects/bind9/lib/dns/nta.c:106:2 (libdns-9.19.6-dev.so+0xcff1f)
#2 deletetreeflat /builds/isc-projects/bind9/lib/dns/rbt.c:2216:5 (libdns-9.19.6-dev.so+0xdf337) (BuildId: 99aa8075eafa451b920a93883c4f94409e999aac)
#3 dns_rbt_destroy2 /builds/isc-projects/bind9/lib/dns/rbt.c:302:2 (libdns-9.19.6-dev.so+0xdf024) (BuildId: 99aa8075eafa451b920a93883c4f94409e999aac)
#4 dns_rbt_destroy /builds/isc-projects/bind9/lib/dns/rbt.c:291:2 (libdns-9.19.6-dev.so+0xdef8b) (BuildId: 99aa8075eafa451b920a93883c4f94409e999aac)
#5 dns__ntatable_destroy /builds/isc-projects/bind9/lib/dns/nta.c:158:2 (libdns-9.19.6-dev.so+0xd00d4) (BuildId: 99aa8075eafa451b920a93883c4f94409e999aac)
#6 dns_ntatable_unref /builds/isc-projects/bind9/lib/dns/nta.c:164:1 (libdns-9.19.6-dev.so+0xd00d4)
#7 dns_ntatable_detach /builds/isc-projects/bind9/lib/dns/nta.c:164:1 (libdns-9.19.6-dev.so+0xd02ae) (BuildId: 99aa8075eafa451b920a93883c4f94409e999aac)
#8 destroy /builds/isc-projects/bind9/lib/dns/view.c:429:3 (libdns-9.19.6-dev.so+0x1d5273) (BuildId: 99aa8075eafa451b920a93883c4f94409e999aac)
#9 dns_view_weakdetach /builds/isc-projects/bind9/lib/dns/view.c:612:3 (libdns-9.19.6-dev.so+0x1d5273)
#10 zone_free /builds/isc-projects/bind9/lib/dns/zone.c:1277:3 (libdns-9.19.6-dev.so+0x1e82d2) (BuildId: 99aa8075eafa451b920a93883c4f94409e999aac)
#11 zone_shutdown /builds/isc-projects/bind9/lib/dns/zone.c:15197:3 (libdns-9.19.6-dev.so+0x1e7911) (BuildId: 99aa8075eafa451b920a93883c4f94409e999aac)
#12 isc__job_cb /builds/isc-projects/bind9/lib/isc/job.c:75:2 (libisc-9.19.6-dev.so+0x4f28d) (BuildId: 8ebe9b001bf573404b12b13e7ea765ff6ccdca0c)
#13 uv__run_idle /usr/src/libuv-v1.44.1/src/unix/loop-watcher.c:68:1 (libuv.so.1+0x1b01a) (BuildId: 120c450d14885aa5308bc95c4ea77de2c2b1cc36)
#14 isc__trampoline_run /builds/isc-projects/bind9/lib/isc/trampoline.c:198:11 (libisc-9.19.6-dev.so+0x79bc7) (BuildId: 8ebe9b001bf573404b12b13e7ea765ff6ccdca0c)
Previous write of size 8 at 0x7b5c00000030 by main thread:
#0 isc_timer_destroy /builds/isc-projects/bind9/lib/isc/timer.c:183:10 (libisc-9.19.6-dev.so+0x74603) (BuildId: 8ebe9b001bf573404b12b13e7ea765ff6ccdca0c)
#1 dns__nta_shutdown_cb /builds/isc-projects/bind9/lib/dns/nta.c:649:3 (libdns-9.19.6-dev.so+0xd1ef9) (BuildId: 99aa8075eafa451b920a93883c4f94409e999aac)
#2 isc__job_cb /builds/isc-projects/bind9/lib/isc/job.c:75:2 (libisc-9.19.6-dev.so+0x4f28d) (BuildId: 8ebe9b001bf573404b12b13e7ea765ff6ccdca0c)
#3 uv__run_idle /usr/src/libuv-v1.44.1/src/unix/loop-watcher.c:68:1 (libuv.so.1+0x1b01a) (BuildId: 120c450d14885aa5308bc95c4ea77de2c2b1cc36)
#4 isc_loopmgr_run /builds/isc-projects/bind9/lib/isc/loop.c:473:2 (libisc-9.19.6-dev.so+0x58606) (BuildId: 8ebe9b001bf573404b12b13e7ea765ff6ccdca0c)
#5 main /builds/isc-projects/bind9/bin/named/main.c:1548:2 (named+0xf92aa) (BuildId: 81a888f44d66f72e3b0a54eb468237b9710f89b2)
Location is heap block of size 832 at 0x7b5c00000000 allocated by main thread:
#0 malloc <null> (named+0x6a451) (BuildId: 81a888f44d66f72e3b0a54eb468237b9710f89b2)
#1 mallocx /builds/isc-projects/bind9/lib/isc/./jemalloc_shim.h:35:10 (libisc-9.19.6-dev.so+0x5bb47) (BuildId: 8ebe9b001bf573404b12b13e7ea765ff6ccdca0c)
#2 mem_get /builds/isc-projects/bind9/lib/isc/mem.c:345:8 (libisc-9.19.6-dev.so+0x5bb47)
#3 isc__mem_get /builds/isc-projects/bind9/lib/isc/mem.c:764:8 (libisc-9.19.6-dev.so+0x5bb47)
#4 nta_create /builds/isc-projects/bind9/lib/dns/nta.c:288:8 (libdns-9.19.6-dev.so+0xd03c7) (BuildId: 99aa8075eafa451b920a93883c4f94409e999aac)
#5 dns_ntatable_add /builds/isc-projects/bind9/lib/dns/nta.c:323:2 (libdns-9.19.6-dev.so+0xd03c7)
#6 named_server_nta /builds/isc-projects/bind9/bin/named/server.c:15948:4 (named+0x10aec7) (BuildId: 81a888f44d66f72e3b0a54eb468237b9710f89b2)
#7 named_control_docommand /builds/isc-projects/bind9/bin/named/control.c:242:12 (named+0xeec75) (BuildId: 81a888f44d66f72e3b0a54eb468237b9710f89b2)
#8 control_command /builds/isc-projects/bind9/bin/named/controlconf.c:390:17 (named+0xf3a59) (BuildId: 81a888f44d66f72e3b0a54eb468237b9710f89b2)
#9 task_run /builds/isc-projects/bind9/lib/isc/task.c:470:4 (libisc-9.19.6-dev.so+0x7205c) (BuildId: 8ebe9b001bf573404b12b13e7ea765ff6ccdca0c)
#10 task__run /builds/isc-projects/bind9/lib/isc/task.c:287:24 (libisc-9.19.6-dev.so+0x7205c)
#11 isc__job_cb /builds/isc-projects/bind9/lib/isc/job.c:75:2 (libisc-9.19.6-dev.so+0x4f28d) (BuildId: 8ebe9b001bf573404b12b13e7ea765ff6ccdca0c)
#12 uv__run_idle /usr/src/libuv-v1.44.1/src/unix/loop-watcher.c:68:1 (libuv.so.1+0x1b01a) (BuildId: 120c450d14885aa5308bc95c4ea77de2c2b1cc36)
#13 isc_loopmgr_run /builds/isc-projects/bind9/lib/isc/loop.c:473:2 (libisc-9.19.6-dev.so+0x58606) (BuildId: 8ebe9b001bf573404b12b13e7ea765ff6ccdca0c)
#14 main /builds/isc-projects/bind9/bin/named/main.c:1548:2 (named+0xf92aa) (BuildId: 81a888f44d66f72e3b0a54eb468237b9710f89b2)
Thread T10 'isc-loop-0010' (tid=4199, running) created by main thread at:
#0 pthread_create <null> (named+0x6bc0d) (BuildId: 81a888f44d66f72e3b0a54eb468237b9710f89b2)
#1 isc_thread_create /builds/isc-projects/bind9/lib/isc/thread.c:70:8 (libisc-9.19.6-dev.so+0x7240a) (BuildId: 8ebe9b001bf573404b12b13e7ea765ff6ccdca0c)
#2 isc_loopmgr_run /builds/isc-projects/bind9/lib/isc/loop.c:467:3 (libisc-9.19.6-dev.so+0x5858c) (BuildId: 8ebe9b001bf573404b12b13e7ea765ff6ccdca0c)
#3 main /builds/isc-projects/bind9/bin/named/main.c:1548:2 (named+0xf92aa) (BuildId: 81a888f44d66f72e3b0a54eb468237b9710f89b2)
SUMMARY: ThreadSanitizer: data race /builds/isc-projects/bind9/lib/dns/nta.c:659:11 in dns__nta_shutdown
```October 2022 (9.16.34, 9.16.34-S1, 9.18.8, 9.19.6)Ondřej SurýOndřej Surýhttps://gitlab.isc.org/isc-projects/bind9/-/issues/3569dns_message_checksig under oss_fuzz is not seeing the data files2022-10-06T09:21:47ZMark Andrewsdns_message_checksig under oss_fuzz is not seeing the data filesoss_fuzz is reporting an assertion that happens when the data files are not available.
https://google.github.io/oss-fuzz/further-reading/fuzzer-environment/ says very little about how to rectify this but as `/tmp` is available we can ju...oss_fuzz is reporting an assertion that happens when the data files are not available.
https://google.github.io/oss-fuzz/further-reading/fuzzer-environment/ says very little about how to rectify this but as `/tmp` is available we can just create a key directory there.October 2022 (9.16.34, 9.16.34-S1, 9.18.8, 9.19.6)https://gitlab.isc.org/isc-projects/bind9/-/issues/3567Bump the minimal libuv version to 1.34.02022-09-29T09:45:35ZOndřej SurýBump the minimal libuv version to 1.34.0By the time BIND 9.20 is release, all distributions without libuv >= 1.34.0 will be either EOL or on life-support. But even with the old distributions, the libuv could be updated from backports (or by installing it locally).
Bumping th...By the time BIND 9.20 is release, all distributions without libuv >= 1.34.0 will be either EOL or on life-support. But even with the old distributions, the libuv could be updated from backports (or by installing it locally).
Bumping the minimal libuv version to 1.34.0 allows us to drop all the libuv shims that we've been maintaining.October 2022 (9.16.34, 9.16.34-S1, 9.18.8, 9.19.6)Ondřej SurýOndřej Surýhttps://gitlab.isc.org/isc-projects/bind9/-/issues/3566UAF in req_senddone on shutdown2022-09-27T12:48:58ZOndřej SurýUAF in req_senddone on shutdownFrom https://gitlab.isc.org/isc-projects/bind9/-/jobs/2793682
```
D:inline:Core was generated by `/builds/isc-projects/bind9/bin/named/.libs/named -D inline-ns2 -X named.lock -m'.
D:inline:Program terminated with signal SIGABRT, Aborted...From https://gitlab.isc.org/isc-projects/bind9/-/jobs/2793682
```
D:inline:Core was generated by `/builds/isc-projects/bind9/bin/named/.libs/named -D inline-ns2 -X named.lock -m'.
D:inline:Program terminated with signal SIGABRT, Aborted.
D:inline:Sent by thr_kill() from pid 27679 and user 1001.
D:inline:#0 0x000000080151369a in thr_kill () from /lib/libc.so.7
D:inline:[Current thread is 1 (LWP 100288)]
D:inline:#0 0x000000080151369a in thr_kill () from /lib/libc.so.7
D:inline:#1 0x0000000801511af4 in raise () from /lib/libc.so.7
D:inline:#2 0x0000000801487719 in abort () from /lib/libc.so.7
D:inline:#3 0x000000000024013d in library_fatal_error (file=0x8008aeb37 "request.c", line=979, format=0x8008a1b5c "%s(): %s() failed with error %d (%s)", args=0x7fffdfffdb30) at main.c:278
D:inline:#4 0x00000008003194a5 in isc_error_fatal (file=0x187c0 <error: Cannot access memory at address 0x187c0>, line=6, format=0x0) at error.c:68
D:inline:#5 0x00000008009c7cf0 in req_senddone (eresult=<optimized out>, region=<optimized out>, arg=<optimized out>) at request.c:993
D:inline:#6 0x0000000800913a75 in send_done (handle=0x801949780, result=ISC_R_SHUTTINGDOWN, cbarg=0x0) at dispatch.c:1920
D:inline:#7 0x0000000800314d88 in isc__nm_udp_send (handle=0x187c0, region=0x7fffdfffdce8, cb=0x800913a40 <send_done>, cbarg=0x0) at netmgr/udp.c:715
D:inline:#8 0x0000000800307a5c in isc_nm_send (handle=0x187c0, region=0x6, cb=0x0, cbarg=0x8015136ba <thr_self+10>) at netmgr/netmgr.c:1984
D:inline:#9 0x0000000800913a10 in dns_dispatch_send (resp=0x805230a00, r=0x7fffdfffdce8, dscp=<optimized out>) at dispatch.c:1971
D:inline:#10 0x00000008009c806c in req_send (request=0x80530db40) at request.c:295
D:inline:#11 0x00000008009c7a96 in req_connected (eresult=ISC_R_SUCCESS, region=<optimized out>, arg=0x80530db40) at request.c:957
D:inline:#12 0x000000080091391e in udp_connected (handle=0x801949780, eresult=ISC_R_SUCCESS, arg=0x805230a00) at dispatch.c:1804
D:inline:#13 0x0000000800307d75 in isc__nm_async_connectcb (worker=<optimized out>, ev0=<optimized out>) at netmgr/netmgr.c:2143
D:inline:#14 0x0000000800305300 in process_netievent (arg=0x80533ad80) at netmgr/netmgr.c:488
D:inline:#15 0x00000008003207a7 in isc__job_cb (idle=0x802f6d548) at job.c:75
D:inline:#16 0x000000080111d5cd in ?? () from /usr/local/lib/libuv.so.1
D:inline:#17 0x0000000801117026 in uv_run () from /usr/local/lib/libuv.so.1
D:inline:#18 0x000000080032792e in loop_run (loop=0x801940530) at loop.c:266
D:inline:#19 0x0000000800326b1c in loop_thread (arg=0x801940530) at loop.c:293
D:inline:#20 0x000000080033d446 in isc__trampoline_run (arg=0x8019f5330) at trampoline.c:198
D:inline:#21 0x000000080133d08c in ?? () from /lib/libthr.so.3
D:inline:#22 0x0000000000000000 in ?? ()
D:inline:Backtrace stopped: Cannot access memory at address 0x7fffdfffe000
```
@each, can you take a look at this?October 2022 (9.16.34, 9.16.34-S1, 9.18.8, 9.19.6)Evan HuntEvan Hunthttps://gitlab.isc.org/isc-projects/bind9/-/issues/3565AddressSanitizer: stack-use-after-scope in dns_tsig_verify (dns_message_check...2022-09-29T10:24:54ZPetr Špačekpspacek@isc.orgAddressSanitizer: stack-use-after-scope in dns_tsig_verify (dns_message_checksig test)### Summary
ASAN error:
```
testing 63 bytes from /builds/isc-projects/bind9/fuzz/dns_message_checksig.in/tsig-reply
=================================================================
==1074==ERROR: AddressSanitizer: stack-use-after-scop...### Summary
ASAN error:
```
testing 63 bytes from /builds/isc-projects/bind9/fuzz/dns_message_checksig.in/tsig-reply
=================================================================
==1074==ERROR: AddressSanitizer: stack-use-after-scope on address 0x7ffe14b1d780 at pc 0x55eeaf01c3ff bp 0x7ffe14b1c990 sp 0x7ffe14b1c160
READ of size 12 at 0x7ffe14b1d780 thread T0
#0 0x55eeaf01c3fe in __asan_memmove (/builds/isc-projects/bind9/fuzz/.libs/dns_message_checksig+0xa63fe) (BuildId: 73cf12c5424a9fda378fddea924b696e6cb966ca)
#1 0x7f93f3d6a227 in memmove /usr/include/x86_64-linux-gnu/bits/string_fortified.h:40:10
#2 0x7f93f3d6a227 in dns_tsig_verify /builds/isc-projects/bind9/lib/dns/tsig.c:1241:3
#3 0x7f93f3dd122d in dns_view_checksig /builds/isc-projects/bind9/lib/dns/view.c:1471:10
#4 0x7f93f38f42a8 in dns_message_checksig /builds/isc-projects/bind9/lib/dns/message.c:3145:12
#5 0x55eeaf058c18 in LLVMFuzzerTestOneInput /builds/isc-projects/bind9/fuzz/dns_message_checksig.c:393:11
#6 0x55eeaf05c189 in test_one_file /builds/isc-projects/bind9/fuzz/main.c:53:3
#7 0x55eeaf05c468 in test_all_from /builds/isc-projects/bind9/fuzz/main.c:89:3
#8 0x55eeaf05bc18 in main /builds/isc-projects/bind9/fuzz/main.c:130:2
#9 0x7f93f2dc5d09 in __libc_start_main csu/../csu/libc-start.c:308:16
#10 0x55eeaef9a569 in _start (/builds/isc-projects/bind9/fuzz/.libs/dns_message_checksig+0x24569) (BuildId: 73cf12c5424a9fda378fddea924b696e6cb966ca)
```
Jobs:
- https://gitlab.isc.org/isc-projects/bind9/-/jobs/2793490: [test-suite.log](/uploads/83a286ac6c986172669ad2e5579a8716/test-suite.log)
- https://gitlab.isc.org/isc-projects/bind9/-/jobs/2793597: [test-suite.log](/uploads/e091fdf3e65bbbd62b360da2d700fe51/test-suite.log)
### BIND version used
4108d79c9a3bc7a617d7ca24adc1180043ee9919 (!6822), but change in this MR affects only tests.
### Steps to reproduce
Run unit:clang:asan job in CI.
### What is the current *bug* behavior?October 2022 (9.16.34, 9.16.34-S1, 9.18.8, 9.19.6)https://gitlab.isc.org/isc-projects/bind9/-/issues/3564Release Checklist for BIND 9.16.34, 9.16.34-S1, 9.18.8, 9.19.62022-10-24T10:01:38ZMichał KępieńRelease Checklist for BIND 9.16.34, 9.16.34-S1, 9.18.8, 9.19.6## Release Schedule
**Code Freeze:** Wednesday, October 5th, 2022
**Tagging Deadline:** Monday, October 10th, 2022
**Public Release:** Wednesday, October 19th, 2022
## Documentation Review Links
**Closed issues assigned to the miles...## Release Schedule
**Code Freeze:** Wednesday, October 5th, 2022
**Tagging Deadline:** Monday, October 10th, 2022
**Public Release:** Wednesday, October 19th, 2022
## Documentation Review Links
**Closed issues assigned to the milestone without a release note:**
- [9.19.6](https://gitlab.isc.org/isc-projects/bind9/-/issues/?sort=created_asc&state=closed&milestone_title=October%202022%20%289.16.34,%209.16.34-S1,%209.18.8,%209.19.6%29¬%5Blabel_name%5D%5B%5D=Release%20Notes¬%5Blabel_name%5D%5B%5D=Duplicate&label_name%5B%5D=v9.19)
- [9.18.8](https://gitlab.isc.org/isc-projects/bind9/-/issues/?sort=created_asc&state=closed&milestone_title=October%202022%20%289.16.34,%209.16.34-S1,%209.18.8,%209.19.6%29¬%5Blabel_name%5D%5B%5D=Release%20Notes¬%5Blabel_name%5D%5B%5D=Duplicate&label_name%5B%5D=v9.18)
- [9.16.34](https://gitlab.isc.org/isc-projects/bind9/-/issues/?sort=created_asc&state=closed&milestone_title=October%202022%20%289.16.34,%209.16.34-S1,%209.18.8,%209.19.6%29¬%5Blabel_name%5D%5B%5D=Release%20Notes¬%5Blabel_name%5D%5B%5D=Duplicate&label_name%5B%5D=v9.16)
**Merge requests merged into the milestone without a release note:**
- [9.19.6](https://gitlab.isc.org/isc-projects/bind9/-/merge_requests?sort=merged_at&state=merged&milestone_title=October%202022%20%289.16.34,%209.16.34-S1,%209.18.8,%209.19.6%29¬[label_name][]=Release%20Notes&target_branch=main)
- [9.18.8](https://gitlab.isc.org/isc-projects/bind9/-/merge_requests?sort=merged_at&state=merged&milestone_title=October%202022%20%289.16.34,%209.16.34-S1,%209.18.8,%209.19.6%29¬[label_name][]=Release%20Notes&target_branch=v9_18)
- [9.16.34](https://gitlab.isc.org/isc-projects/bind9/-/merge_requests?sort=merged_at&state=merged&milestone_title=October%202022%20%289.16.34,%209.16.34-S1,%209.18.8,%209.19.6%29¬[label_name][]=Release%20Notes&target_branch=v9_16)
**Merge requests merged into the milestone without a `CHANGES` entry:**
- [9.19.6](https://gitlab.isc.org/isc-projects/bind9/-/merge_requests?sort=merged_at&state=merged&milestone_title=October%202022%20%289.16.34,%209.16.34-S1,%209.18.8,%209.19.6%29&label_name[]=No%20CHANGES&target_branch=main)
- [9.18.8](https://gitlab.isc.org/isc-projects/bind9/-/merge_requests?sort=merged_at&state=merged&milestone_title=October%202022%20%289.16.34,%209.16.34-S1,%209.18.8,%209.19.6%29&label_name[]=No%20CHANGES&target_branch=v9_18)
- [9.16.34](https://gitlab.isc.org/isc-projects/bind9/-/merge_requests?sort=merged_at&state=merged&milestone_title=October%202022%20%289.16.34,%209.16.34-S1,%209.18.8,%209.19.6%29&label_name[]=No%20CHANGES&target_branch=v9_16)
## Release Checklist
### Before the Code Freeze
- [x] ***(QA)*** Inform Support and Marketing of impending release (and give estimated release dates).
- [x] ***(QA)*** Ensure there are no permanent test failures on any platform.
- [x] ***(QA)*** Check Perflab to ensure there has been no unexplained drop in performance for the versions being released.
- [x] ***(QA)*** Check whether all issues assigned to the release milestone are resolved[^1].
- [x] ***(QA)*** Ensure that there are no outstanding merge requests in the private repository[^1] (Subscription Edition only).
- [x] ***(QA)*** Ensure all merge requests marked for backporting have been indeed backported.
- [x] ***(QA)*** Update GitLab settings for all maintained branches to disallow merging to them.
- [x] ***(QA)*** Announce (on Mattermost) that the code freeze is in effect.
### Before the Tagging Deadline
- [x] ***(QA)*** Ensure release notes are correct, ask Support and Marketing to check them as well.
- [x] ***(QA)*** Add a release marker to `CHANGES`.
- [x] ***(QA)*** Add a release marker to `CHANGES.SE` (Subscription Edition only).
- [x] ***(QA)*** Update BIND 9 version in `configure.ac` (9.18+) or `version` (9.16).
- [x] ***(QA)*** Rebuild `configure` using Autoconf on `docs.isc.org` (9.16).
- [x] ***(QA)*** Tag the releases in the private repository (`git tag -s -m "BIND 9.x.y" v9_x_y`).
### Before the ASN Deadline (for ASN Releases) or the Public Release Date (for Regular Releases)
- [x] ***(QA)*** Check that the formatting is correct for HTML and PDF versions of release notes.
- [x] ***(QA)*** Check that the formatting of the generated man pages is correct.
- [x] ***(QA)*** Verify GitLab CI results for the tags created and sign off on the releases to be published.
- [x] ***(QA)*** Update GitLab settings for all maintained branches to allow merging to them again.
- [x] ***(QA)*** Prepare and merge MRs resetting the release notes and updating the version string for each maintained branch.
- [x] ***(QA)*** Announce (on Mattermost) that the code freeze is over.
- [x] ***(QA)*** Request signatures for the tarballs, providing their location and checksums.
- [x] ***(Signers)*** Validate tarball checksums, sign tarballs, and upload signatures.
- [x] ***(QA)*** Verify tarball signatures and check tarball checksums again.
- [x] ***(Support)*** Pre-publish ASN and/or Subscription Edition tarballs so that packages can be built.
- [x] ***(QA)*** Build and test ASN and/or Subscription Edition packages.
- [x] ***(QA)*** Notify Support that the releases have been prepared.
- [x] ***(Support)*** Send out ASNs (if applicable).
### On the Day of Public Release
- [x] ***(Support)*** Wait for clearance from Security Officer to proceed with the public release (if applicable).
- [x] ***(Support)*** Place tarballs in public location on FTP site.
- [x] ***(Support)*** Publish links to downloads on ISC website.
- [x] ***(Support)*** Write release email to *bind-announce*.
- [x] ***(Support)*** Write email to *bind-users* (if a major release).
- [x] ***(Support)*** Send eligible customers updated links to the Subscription Edition (update the -S edition delivery tickets, even if those links were provided earlier via an ASN ticket).
- [x] ***(Support)*** Update tickets in case of waiting support customers.
- [x] ***(QA)*** Build and test any outstanding private packages.
- [x] ***(QA)*** Build public RPMs.
- [x] ***(SwEng)*** Build Debian/Ubuntu packages.
- [x] ***(SwEng)*** Update Docker images.
- [x] ***(QA)*** Inform Marketing of the release.
- [x] ***(Marketing)*** Post short note to Twitter.
- [x] ***(Marketing)*** Update [Wikipedia entry for BIND](https://en.wikipedia.org/wiki/BIND).
- [x] ***(Marketing)*** Write blog article (if a major release).
- [x] ***(QA)*** Ensure all new tags are annotated and signed.
- [x] ***(QA)*** Push tags for the published releases to the public repository.
- [x] ***(QA)*** Merge published release tags (non-linearly) back into the their relevant development/maintenance branches.
- [x] ***(QA)*** Sanitize confidential issues which are assigned to the current release milestone and do not describe a security vulnerability, then make them public.
- [x] ***(QA)*** Sanitize confidential issues which are assigned to older release milestones and describe security vulnerabilities, then make them public if appropriate[^2].
- [x] ***(QA)*** Update QA tools used in GitLab CI (e.g. Flake8, PyLint) by modifying the relevant `Dockerfile`.
[^1]: If not, use the time remaining until the tagging deadline to ensure all outstanding issues are either resolved or moved to a different milestone.
[^2]: As a rule of thumb, security vulnerabilities which have reproducers merged to the public repository are considered okay for full disclosure.October 2022 (9.16.34, 9.16.34-S1, 9.18.8, 9.19.6)Michał KępieńMichał Kępień2022-10-19https://gitlab.isc.org/isc-projects/bind9/-/issues/3562suffix may be used before being assigned in qmin/ans3/ans.py2022-09-29T10:03:12ZMark Andrewssuffix may be used before being assigned in qmin/ans3/ans.pyCoverity reports `Bad use of null-like value`
```
139 if lqname == "zoop.boing." and rrtype == NS:
CID 350722 (#1 of 7): Bad use of null-like value (FORWARD_NULL) [select issue]
140 r.answer.append(
141 dns.r...Coverity reports `Bad use of null-like value`
```
139 if lqname == "zoop.boing." and rrtype == NS:
CID 350722 (#1 of 7): Bad use of null-like value (FORWARD_NULL) [select issue]
140 r.answer.append(
141 dns.rrset.from_text(lqname + suffix, 1, IN, NS, "ns3." + suffix)
142 )
143 r.flags |= dns.flags.AA
11. Condition endswith(lqname, "icky.ptang.zoop.boing."), taking true branch.
144 elif endswith(lqname, "icky.ptang.zoop.boing."):
CID 350722 (#5 of 7): Bad use of null-like value (FORWARD_NULL)
12. invalid_operation: Invalid operation on null-like value suffix.
145 r.authority.append(
146 dns.rrset.from_text(
147 "icky.ptang.zoop.boing." + suffix,
148 1,
149 IN,
150 NS,
151 "a.bit.longer.ns.name." + suffix,
152 )
153 )
154 elif endswith("icky.ptang.zoop.boing.", lqname):
CID 350722 (#3 of 7): Bad use of null-like value (FORWARD_NULL) [select issue]
155 r.authority.append(
156 dns.rrset.from_text(
157 "zoop.boing." + suffix,
158 1,
159 IN,
160 SOA,
161 "ns3." + suffix + " hostmaster.arpa. 2018050100 1 1 1 1",
162 )
163 )
164 if bad:
165 r.set_rcode(NXDOMAIN)
166 if ugly:
167 r.set_rcode(FORMERR)
168 elif endswith(lqname, "zoop.boing."):
CID 350722 (#4 of 7): Bad use of null-like value (FORWARD_NULL) [select issue]
169 r.authority.append(
```October 2022 (9.16.34, 9.16.34-S1, 9.18.8, 9.19.6)Mark AndrewsMark Andrewshttps://gitlab.isc.org/isc-projects/bind9/-/issues/3560timer callback on already destroyed resolver object2022-10-06T09:28:19ZOndřej Surýtimer callback on already destroyed resolver objectLooks like the timer wasn't stopped or was recreated or something :smile:
This is 9.19 only
```
D:statistics:Core was generated by `/builds/isc-projects/bind9/bin/named/.libs/named -D statistics-ns2 -X named.loc'.
D:statistics:Program...Looks like the timer wasn't stopped or was recreated or something :smile:
This is 9.19 only
```
D:statistics:Core was generated by `/builds/isc-projects/bind9/bin/named/.libs/named -D statistics-ns2 -X named.loc'.
D:statistics:Program terminated with signal SIGABRT, Aborted.
D:statistics:#0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
D:statistics:[Current thread is 1 (Thread 0x7f7c0ff7f700 (LWP 15583))]
D:statistics:#0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
D:statistics:#1 0x00007f7c132ae859 in __GI_abort () at abort.c:79
D:statistics:#2 0x00005581b7426cfb in assertion_failed (file=<optimized out>, line=<optimized out>, type=isc_assertiontype_require, cond=0x7f7c13d50100 "((res) != ((void *)0) && ((const isc__magic_t *)(res))->magic == ((('R') << 24 | ('e') << 16 | ('s') << 8 | ('!'))))") at main.c:238
D:statistics:#3 0x00007f7c13dd63ed in isc_assertion_failed (file=file@entry=0x7f7c13d4f156 "resolver.c", line=line@entry=10736, type=type@entry=isc_assertiontype_require, cond=cond@entry=0x7f7c13d50100 "((res) != ((void *)0) && ((const isc__magic_t *)(res))->magic == ((('R') << 24 | ('e') << 16 | ('s') << 8 | ('!'))))") at assertions.c:49
D:statistics:#4 0x00007f7c13c95256 in dns_resolver_createfetch (res=<optimized out>, name=name@entry=0x7f7c10056180, type=type@entry=48, domain=domain@entry=0x0, nameservers=nameservers@entry=0x0, forwarders=forwarders@entry=0x0, client=0x0, id=0, options=32802, depth=0, qc=0x0, task=0x7f7c10078240, action=0x7f7c13cf8eae <keyfetch_done>, arg=0x7f7c10056180, rdataset=0x7f7c10056400, sigrdataset=0x7f7c10056470, fetchp=0x7f7c100564f0) at resolver.c:10772
D:statistics:#5 0x00007f7c13cefce7 in zone_refreshkeys (zone=zone@entry=0x7f7be2603000) at zone.c:11301
D:statistics:#6 0x00007f7c13d113fd in zone_maintenance (zone=0x7f7be2603000) at zone.c:11536
D:statistics:#7 0x00007f7c13d119aa in zone_timer (arg=<optimized out>) at zone.c:15206
D:statistics:#8 0x00007f7c13dfe870 in timer_cb (handle=<optimized out>) at timer.c:113
D:statistics:#9 0x00007f7c13770256 in uv.run_timers () from /lib/x86_64-linux-gnu/libuv.so.1
D:statistics:#10 0x00007f7c137737ba in uv_run () from /lib/x86_64-linux-gnu/libuv.so.1
D:statistics:#11 0x00007f7c13de9309 in loop_run (loop=loop@entry=0x7f7c106a52e0) at loop.c:266
D:statistics:#12 0x00007f7c13de9374 in loop_thread (arg=0x7f7c106a52e0) at loop.c:293
D:statistics:#13 0x00007f7c13e03065 in isc__trampoline_run (arg=0x5581b89f1410) at trampoline.c:198
D:statistics:#14 0x00007f7c13486609 in start_thread (arg=<optimized out>) at pthread_create.c:477
D:statistics:#15 0x00007f7c133ab133 in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95
```October 2022 (9.16.34, 9.16.34-S1, 9.18.8, 9.19.6)Ondřej SurýOndřej Surýhttps://gitlab.isc.org/isc-projects/bind9/-/issues/3559Provide custom isc_mem based allocators for external libraries2022-09-29T09:47:35ZOndřej SurýProvide custom isc_mem based allocators for external librariesSome of the external libraries that we use in BIND 9 provide a way how to override their internal allocators. Create separate memory context for each of the libraries.Some of the external libraries that we use in BIND 9 provide a way how to override their internal allocators. Create separate memory context for each of the libraries.October 2022 (9.16.34, 9.16.34-S1, 9.18.8, 9.19.6)