ISC Open Source Projects issueshttps://gitlab.isc.org/groups/isc-projects/-/issues2020-12-17T16:10:12Zhttps://gitlab.isc.org/isc-projects/bind9/-/issues/324add obsolete answer-cookie to master.2020-12-17T16:10:12ZMark Andrewsadd obsolete answer-cookie to master.BIND-9.13.2https://gitlab.isc.org/isc-projects/bind9/-/issues/1674Consider enforcing query ID check on all messages in an AXFR2020-12-17T16:10:12ZBrian ConryConsider enforcing query ID check on all messages in an AXFRPer discussion in mattermost on Feb 28, in relation to customer ticket #16008, consider enforcing query ID checks on all messages in an AXFR rather than the current practice of "Skip check for second and subsequent messages if the query ...Per discussion in mattermost on Feb 28, in relation to customer ticket #16008, consider enforcing query ID checks on all messages in an AXFR rather than the current practice of "Skip check for second and subsequent messages if the query is AXFR."
https://mattermost.isc.org/isc/pl/fhjo75oq77ddjrhc8gstw3e9mr
https://support.isc.org/Ticket/Display.html?id=16008May 2020 (9.11.19, 9.11.19-S1, 9.14.12, 9.16.3)Michał KępieńMichał Kępieńhttps://gitlab.isc.org/isc-projects/bind9/-/issues/1969Silence CPPCHECK warnings2020-12-17T13:20:36ZMark AndrewsSilence CPPCHECK warningsJob [#972939](https://gitlab.isc.org/isc-projects/bind9/-/jobs/972939) failed for e82527727c42f9bb3e3a6c4f5b2dfd7a13a67c4c:
https://isc-projects.isc-pag.es/-/bind9/-/jobs/972939/artifacts/cppcheck_html/index.html
These appear to be fal...Job [#972939](https://gitlab.isc.org/isc-projects/bind9/-/jobs/972939) failed for e82527727c42f9bb3e3a6c4f5b2dfd7a13a67c4c:
https://isc-projects.isc-pag.es/-/bind9/-/jobs/972939/artifacts/cppcheck_html/index.html
These appear to be false positives with the exception of a now redundant NULL check in update.cJuly 2020 (9.11.21, 9.11.21-S1, 9.16.5, 9.17.3)Mark AndrewsMark Andrewshttps://gitlab.isc.org/isc-projects/bind9/-/issues/2351catgets crashes on openWRT2020-12-17T11:32:15ZThomas Markwaldercatgets crashes on openWRTAs reported by an ISC DCHP user, a segfault occurs in the call to catgets() on openWRT in this issue:
https://gitlab.isc.org/isc-projects/dhcp/-/issues/156
It seems that catopen() returns -1 as the catalogs are not present. Subsequent...As reported by an ISC DCHP user, a segfault occurs in the call to catgets() on openWRT in this issue:
https://gitlab.isc.org/isc-projects/dhcp/-/issues/156
It seems that catopen() returns -1 as the catalogs are not present. Subsequent calls to catgets() with an invalid pointer value of -1 cause it to segfault. Preliminary testing under Ubuntu 18.04 shows the catopen() returns 0 (contrary to the man page) but that catgets() handles a null pointer value safely.
This is present in 9.1.14.https://gitlab.isc.org/isc-projects/bind9/-/issues/2150INSIST(ISC_LIST_EMPTY(res->dbuckets[i].list)); assertion failure during shutdown2020-12-16T22:13:12ZMark AndrewsINSIST(ISC_LIST_EMPTY(res->dbuckets[i].list)); assertion failure during shutdownJob [#1157253](https://gitlab.isc.org/isc-projects/bind9/-/jobs/1157253) failed for 7e39ead11bfa4b109897e75683af5b03f5f89eb4:
```
I:rpzrecurse:Core dump(s) found: rpzrecurse/ns3/core.7743
6956D:rpzrecurse:backtrace from rpzrecurse/ns3/...Job [#1157253](https://gitlab.isc.org/isc-projects/bind9/-/jobs/1157253) failed for 7e39ead11bfa4b109897e75683af5b03f5f89eb4:
```
I:rpzrecurse:Core dump(s) found: rpzrecurse/ns3/core.7743
6956D:rpzrecurse:backtrace from rpzrecurse/ns3/core.7743:
6957D:rpzrecurse:--------------------------------------------------------------------------------
6958D:rpzrecurse:Core was generated by `/builds/isc-projects/bind9/bin/named/.libs/lt-named -D rpzrecurse-ns3 -X named.'.
6959D:rpzrecurse:Program terminated with signal SIGABRT, Aborted.
6960D:rpzrecurse:#0 0x00007f7160dcb438 in __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:54
6961D:rpzrecurse:[Current thread is 1 (Thread 0x7f7151321700 (LWP 7793))]
6962D:rpzrecurse:#0 0x00007f7160dcb438 in __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:54
6963D:rpzrecurse:#1 0x00007f7160dcd03a in __GI_abort () at abort.c:89
6964D:rpzrecurse:#2 0x0000000000428ba5 in assertion_failed (file=<optimized out>, line=<optimized out>, type=isc_assertiontype_insist, cond=0x7f7163056920 "((res->dbuckets[i].list).head == ((void *)0))") at main.c:254
6965D:rpzrecurse:#3 0x00007f71632c689a in isc_assertion_failed (file=file@entry=0x7f71630536e0 "resolver.c", line=line@entry=10034, type=type@entry=isc_assertiontype_insist, cond=cond@entry=0x7f7163056920 "((res->dbuckets[i].list).head == ((void *)0))") at assertions.c:46
6966D:rpzrecurse:#4 0x00007f7162faadb7 in destroy (res=0x7f7163580340) at resolver.c:10034
6967D:rpzrecurse:#5 dns_resolver_detach (resp=resp@entry=0x7f7144005488) at resolver.c:10578
6968D:rpzrecurse:#6 0x00007f7162fea2cc in destroy (view=0x7f7144005460) at view.c:407
6969D:rpzrecurse:#7 0x00007f7162feb028 in dns_view_weakdetach (viewp=viewp@entry=0x7f7144006bd0) at view.c:727
6970D:rpzrecurse:#8 0x00007f7162ff7727 in zone_free (zone=0x7f7144006260) at zone.c:1197
6971D:rpzrecurse:#9 0x00007f716300d5cc in zone_shutdown (task=<optimized out>, event=<optimized out>) at zone.c:14069
6972D:rpzrecurse:#10 0x00007f71632e7629 in dispatch (threadid=<optimized out>, manager=<optimized out>) at task.c:1152
6973D:rpzrecurse:#11 run (queuep=<optimized out>) at task.c:1344
6974D:rpzrecurse:#12 0x00007f71619476ba in start_thread (arg=0x7f7151321700) at pthread_create.c:333
6975D:rpzrecurse:#13 0x00007f7160e9d4dd in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109
6976D:rpzrecurse:--------------------------------------------------------------------------------
6977D:rpzrecurse:full backtrace from rpzrecurse/ns3/core.7743 saved in core.7743-backtrace.txt
6978D:rpzrecurse:core dump rpzrecurse/ns3/core.7743 archived as rpzrecurse/ns3/core.7743.gz
6979R:rpzrecurse:FAIL
```December 2020 (9.11.26, 9.11.26-S1, 9.16.10, 9.16.10-S1, 9.17.8)https://gitlab.isc.org/isc-projects/bind9/-/issues/2321Refactor netmgr2020-12-16T21:06:24ZOndřej SurýRefactor netmgrWhile working on fixing the bugs in the netmgr, it was discovered that stacking the netmgr APIs on top of each other is very error prone, confusing and mostly unfixable. It was proposed to rewrite the tcpdns using the libuv only and alo...While working on fixing the bugs in the netmgr, it was discovered that stacking the netmgr APIs on top of each other is very error prone, confusing and mostly unfixable. It was proposed to rewrite the tcpdns using the libuv only and along with the other fixes to refactor the netmgr API together with adding unit tests.
The `netmgr/` directory and the unit tests needs to be backported to 9.16 together with relevant changes, but we must not backport any netmgr-client changes outside `netmgr/` yet.December 2020 (9.11.26, 9.11.26-S1, 9.16.10, 9.16.10-S1, 9.17.8)Ondřej SurýOndřej Surýhttps://gitlab.isc.org/isc-projects/bind9/-/issues/1816include transport used in dig response (udp/tcp)2020-12-16T21:06:24ZAnand Buddhdevinclude transport used in dig response (udp/tcp)### Summary
BIND does not return a minimal response to an ANY query with the `minimal-any` option enabled.
### BIND version used
```
BIND 9.16.2 (Stable Release) <id:b310dc7>
running on Linux x86_64 3.10.0-957.21.3.el7.x86_64 #1 SMP T...### Summary
BIND does not return a minimal response to an ANY query with the `minimal-any` option enabled.
### BIND version used
```
BIND 9.16.2 (Stable Release) <id:b310dc7>
running on Linux x86_64 3.10.0-957.21.3.el7.x86_64 #1 SMP Tue Jun 18 16:35:19 UTC 2019
built by make with '--build=x86_64-redhat-linux-gnu' '--host=x86_64-redhat-linux-gnu' '--program-prefix=' '--disable-dependency-tracking' '--prefix=/usr' '--exec-prefix=/usr' '--bindir=/usr/bin' '--sbindir=/usr/sbin' '--sysconfdir=/etc' '--datadir=/usr/share' '--includedir=/usr/include' '--libdir=/usr/lib64' '--libexecdir=/usr/libexec' '--localstatedir=/var' '--sharedstatedir=/var/lib' '--mandir=/usr/share/man' '--infodir=/usr/share/info' '--sysconfdir=/etc/named' '--disable-static' '--with-pic' '--without-python' '--with-libtool' '--without-lmdb' 'build_alias=x86_64-redhat-linux-gnu' 'host_alias=x86_64-redhat-linux-gnu' 'CFLAGS=-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -m64 -mtune=generic' 'LDFLAGS=-Wl,-z,relro ' 'PKG_CONFIG_PATH=:/usr/lib64/pkgconfig:/usr/share/pkgconfig'
compiled by GCC 4.8.5 20150623 (Red Hat 4.8.5-39)
compiled with OpenSSL version: OpenSSL 1.0.2k-fips 26 Jan 2017
linked to OpenSSL version: OpenSSL 1.0.2k-fips 26 Jan 2017
compiled with libxml2 version: 2.9.1
linked to libxml2 version: 20901
compiled with json-c version: 0.11
linked to json-c version: 0.11
compiled with zlib version: 1.2.7
linked to zlib version: 1.2.7
threads support is enabled
default paths:
named configuration: /etc/named/named.conf
rndc configuration: /etc/named/rndc.conf
DNSSEC root key: /etc/named/bind.keys
nsupdate session key: /var/run/named/session.key
named PID file: /var/run/named/named.pid
named lock file: /var/run/named/named.lock
```
### Steps to reproduce
1. Set up a BIND server with at least one zone (master, slave, doesn't matter)
2. Set `minimal-any` to `yes` in named.conf
3. Start the name server
4. Query this name server for zone/ANY over UDP
### What is the current *bug* behavior?
BIND returns all the records at the queried name
### What is the expected *correct* behavior?
I expect BIND to return only one RRset
### Relevant configuration files
n/a
### Relevant logs and/or screenshots
n/a
### Possible fixes
n/aNovember 2020 (9.11.25, 9.11.25-S1, 9.16.9, 9.16.9-S1, 9.17.7)https://gitlab.isc.org/isc-projects/bind9/-/issues/2305Did we set the max-recursion-queries limit too low in our CVE-2020-8616 fix?2020-12-16T20:50:12ZMichael McNallyDid we set the max-recursion-queries limit too low in our CVE-2020-8616 fix?A [Support customer](https://support.isc.org/Ticket/Display.html?id=17319) has reported to us that the first time they query google.de on a server with a cold cache they get a SERVFAIL. Subsequent queries succeed. They asked us about t...A [Support customer](https://support.isc.org/Ticket/Display.html?id=17319) has reported to us that the first time they query google.de on a server with a cold cache they get a SERVFAIL. Subsequent queries succeed. They asked us about this because the behavior differed from an earlier version of BIND which did not exhibit the issue.
After some troubleshooting, it turns out that, due to a combination of factors -- some specific to the domain but also some applying to the server, they are hitting the max-recursion-queries limit of 75 queries that was set as part of the remediation for [CVE-2020-8616](https://kb.isc.org/docs/cve-2020-8616) (intended to prevent an exploit, demonstrated as a proof-of-concept by the researchers who reported it, that could send a server chasing a huge number of queries when processing a referral.)
The situation reported by the customer seems to demonstrate that a server with a not-very-unusual configuration can hit the limit while processing a common, fairly high-profile zone. Should we then adjust the limit, make changes to the log message visibility when the limit is hit, and/or make other changes?December 2020 (9.11.26, 9.11.26-S1, 9.16.10, 9.16.10-S1, 9.17.8)https://gitlab.isc.org/isc-projects/kea/-/issues/1479Is there a reason why Kea must have an IP address and not a FQDN to specify "...2020-12-16T17:56:05ZMichael McNallyIs there a reason why Kea must have an IP address and not a FQDN to specify "next-server"?A [Support customer asks](https://support.isc.org/Ticket/Display.html?id=17237) whether there is a reason why "next-server" values must be specified as IP addresses in Kea, as opposed to also allowing fully-qualified domain names, as was...A [Support customer asks](https://support.isc.org/Ticket/Display.html?id=17237) whether there is a reason why "next-server" values must be specified as IP addresses in Kea, as opposed to also allowing fully-qualified domain names, as was possible in ISC DHCP:
> With ISC DHCP config, one could specify next-server as FQDN and dhcpd would resolve it on its start up and give clients as an IP.
>
> With KEA, it is not possible as it demands to be an IP address and I was wondering about the reasons for this.
>
> You see, our problem stemming from this is the fact TFTP server IP changes over time for various reasons - HW failures or tech-refresh, VM or containers moved from one hypervisor to another, etc.
>
> With those changes we also have to somehow track this from KEA config stand point and make corresponding changes to subnet configs, which is tedious task as it would require a lot of changes as we have a lot of subnets in our KEA instances.
>
> I know that ISC DHCP way was not perfect either as it required a dhcpd restart on IP changes, but at least it did not require a config change
I can foresee some problems with this, perhaps the most obvious being ambiguity if the FQDN does not resolve to a single address, but is there a literal requirement that constrains us here or is this just a design choice?
Alternatively (and probably preferably if we have a practical alternative to offer) what would we counsel the operator to do instead if we choose not to relax the current constraint?outstandinghttps://gitlab.isc.org/isc-projects/kea/-/issues/1617bump up kea version2020-12-16T13:26:36ZWlodzimierz Wencelbump up kea versionkea1.9.4Wlodzimierz WencelWlodzimierz Wencelhttps://gitlab.isc.org/isc-projects/kea/-/issues/881design for BOOTP hook2020-12-16T10:47:06ZTomek Mrugalskidesign for BOOTP hookWe want to implement BOOTP support in 1.7. There is a business need for it. On the other hand, we don't want to scatter the code for it all around Kea, so the code can be removed.
This ticket covers writing bootp desgin.
Requirements:
...We want to implement BOOTP support in 1.7. There is a business need for it. On the other hand, we don't want to scatter the code for it all around Kea, so the code can be removed.
This ticket covers writing bootp desgin.
Requirements:
- need to be implemented as a hook
- need to explain how to handle infinite leases (there are no lease lifetimes in bootp)
- need to explain how to handle 2 packet exchanges
- bootp does not have any options (to be confirmed)
One proposal that came up is to have a pkt4_receive hook that would insert absolute minimum necessary for the Kea engine to think it's a DHCPREQUEST (insert magic cookie, dhcp message type option) and another hook at pkt4_send that would remove those and other options being assigned.
The major benefit of this approach is that we could use host reservations, client classification and other Kea features.
Another thing to consider is that maybe we could introduce special class BOOTP, so it would be easy to understand which addresses will be assigned.kea1.7.3Francis DupontFrancis Duponthttps://gitlab.isc.org/isc-projects/bind9/-/issues/1830Feature request: Adapt BIND cache management so that fetched RRsets with TTL=...2020-12-15T12:49:51ZCathy AlmondFeature request: Adapt BIND cache management so that fetched RRsets with TTL=0 use a different 'throw-away' cacheInspired by [Support ticket #16297](https://support.isc.org/Ticket/Display.html?id=16297)
The problem is the cache can get filled up with TTL=0 records, causing the resolver to 'grind to a halt.'
For BIND resolvers that routinely field...Inspired by [Support ticket #16297](https://support.isc.org/Ticket/Display.html?id=16297)
The problem is the cache can get filled up with TTL=0 records, causing the resolver to 'grind to a halt.'
For BIND resolvers that routinely field a large proportion of client queries that result in authoritative RRsets with TTL=0 (and we only have to look back at other reports where we've had problems making sure that TTL=0 content is handled properly and served solely to the clients making the query originally or which have been added to the fetch via clients-per-query before it has been complete, to know that these environments **do** exist...), can't we just avoid adding them to cache at all?
Suggestion:
A new TTL=0 cache
This would be used as a temporary storage place for *all* content that comes back with TTL=0 but which needs to persist for the lifetime of the client queries that are waiting for recursion to complete (so might include some intermediate fetch results as well as the answers needed for the client query responses. When serving responses to clients, use both main cache and TTL=0 cache. (OR perhaps there could be a way to flag to the tasks responding to clients that they should also look in TTL=0 cache when assembling the query response)
I would hope, given that the content is due to be thrown away as soon as all the clients have been responded to, that it might be easier to manage this in terms of access control than in main cache.
The big advantage to main cache, is that this content is kept out of it, thus reducing cache flux and cache maintenance overhead involved in adding and then cleaning up these non-persisting RRsets.
(Implementing this would also obviate the need to action #1829 )January 2021 (9.11.27, 9.11.27-S1, 9.16.11, 9.16.11-S1, 9.17.9)https://gitlab.isc.org/isc-projects/bind9/-/issues/1975host does not report missing records on default lookups2020-12-15T12:38:43ZPetr Menšíkhost does not report missing records on default lookups<!--
If the bug you are reporting is potentially security-related - for example,
if it involves an assertion failure or other crash in `named` that can be
triggered repeatedly - then please do *NOT* report it here, but send an
email to [...<!--
If the bug you are reporting is potentially security-related - for example,
if it involves an assertion failure or other crash in `named` that can be
triggered repeatedly - then please do *NOT* report it here, but send an
email to [security-officer@isc.org](security-officer@isc.org).
-->
### Summary
host does not report missing records, when no type was gived and name does exist, but no queried records exist.
### BIND version used
```
BIND 9.16.4-RedHat-9.16.4-2.fc32 (Stable Release) <id:0849b42>
running on Linux x86_64 5.6.19-300.fc32.x86_64 #1 SMP Wed Jun 17 16:10:48 UTC 2020
built by make with '--build=x86_64-redhat-linux-gnu' '--host=x86_64-redhat-linux-gnu' '--program-prefix=' '--disable-dependency-tracking' '--prefix=/usr' '--exec-prefix=/usr' '--bindir=/usr/bin' '--sbindir=/usr/sbin' '--sysconfdir=/etc' '--datadir=/usr/share' '--includedir=/usr/include' '--libdir=/usr/lib64' '--libexecdir=/usr/libexec' '--sharedstatedir=/var/lib' '--mandir=/usr/share/man' '--infodir=/usr/share/info' '--with-python=/usr/bin/python3' '--with-libtool' '--localstatedir=/var' '--with-pic' '--disable-static' '--includedir=/usr/include/bind9' '--with-tuning=large' '--with-libidn2' '--with-maxminddb' '--enable-native-pkcs11' '--with-pkcs11=/usr/lib64/pkcs11/libsofthsm2.so' '--with-dlopen=yes' '--with-dlz-ldap=yes' '--with-dlz-postgres=yes' '--with-dlz-mysql=yes' '--with-dlz-filesystem=yes' '--with-gssapi=yes' '--disable-isc-spnego' '--with-lmdb=yes' '--without-libjson' '--with-json-c' '--enable-dnstap' '--with-cmocka' '--enable-fixed-rrset' '--with-docbook-xsl=/usr/share/sgml/docbook/xsl-stylesheets' '--enable-full-report' 'build_alias=x86_64-redhat-linux-gnu' 'host_alias=x86_64-redhat-linux-gnu' 'CFLAGS= -O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -fexceptions -fstack-protector-strong -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection' 'LDFLAGS=-Wl,-z,relro -Wl,--as-needed -Wl,-z,now -specs=/usr/lib/rpm/redhat/redhat-hardened-ld' 'LT_SYS_LIBRARY_PATH=/usr/lib64:' 'PKG_CONFIG_PATH=:/usr/lib64/pkgconfig:/usr/share/pkgconfig'
compiled by GCC 10.1.1 20200507 (Red Hat 10.1.1-1)
compiled with OpenSSL version: OpenSSL 1.1.1g FIPS 21 Apr 2020
linked to OpenSSL version: OpenSSL 1.1.1g FIPS 21 Apr 2020
compiled with libxml2 version: 2.9.10
linked to libxml2 version: 20910
compiled with json-c version: 0.13.1
linked to json-c version: 0.13.1
compiled with zlib version: 1.2.11
linked to zlib version: 1.2.11
linked to maxminddb version: 1.4.2
compiled with protobuf-c version: 1.3.2
linked to protobuf-c version: 1.3.2
threads support is enabled
default paths:
named configuration: /etc/named.conf
rndc configuration: /etc/rndc.conf
DNSSEC root key: /etc/bind.keys
nsupdate session key: /var/run/named/session.key
named PID file: /var/run/named/named.pid
named lock file: /var/run/named/named.lock
geoip-directory: /usr/share/GeoIP
```
### Steps to reproduce
host 1.0.0.127.in-addr.arpa
### What is the current *bug* behavior?
Nothing is printed at all. No error, no missing type.
### What is the expected *correct* behavior?
Host should print similar message when type is explicitly given.
1.0.0.127.in-addr.arpa has no A, AAAA nor MX record
### Relevant configuration files
none
### Relevant logs and/or screenshots
```
host 1.0.0.127.in-addr.arpa
host -t mx 1.0.0.127.in-addr.arpa
1.0.0.127.in-addr.arpa has no MX record
```
### Possible fixes
Some counter for summary for one name, when all of them got responses of NOERROR
https://gitlab.isc.org/isc-projects/bind9/-/blob/main/bin/dig/host.c#L568
Reported originally on Red Hat bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1850685January 2021 (9.11.27, 9.11.27-S1, 9.16.11, 9.16.11-S1, 9.17.9)https://gitlab.isc.org/isc-projects/kea/-/issues/1611date +%s -d '4 seconds' not working on alpine2020-12-14T17:45:03ZAndrei Pavelandrei@isc.orgdate +%s -d '4 seconds' not working on alpine`date +%s -d '4 seconds'` -> `$(($(date +%s) + 4))` for alpine support`date +%s -d '4 seconds'` -> `$(($(date +%s) + 4))` for alpine supportkea1.9.3Andrei Pavelandrei@isc.orgAndrei Pavelandrei@isc.orghttps://gitlab.isc.org/isc-projects/kea/-/issues/16091.9.3 release changes2020-12-14T14:32:08ZWlodzimierz Wencel1.9.3 release changeskea1.9.3Wlodzimierz WencelWlodzimierz Wencelhttps://gitlab.isc.org/isc-projects/bind9/-/issues/385Add a built-in ipv4only.arpa default zone.2020-12-14T13:25:20ZMark AndrewsAdd a built-in ipv4only.arpa default zone.Add the ipv4only.arpa zone with the well known contents with similar constraints to empty-zones.
Check that DNS64 appropriately modifies the contents if configured.Add the ipv4only.arpa zone with the well known contents with similar constraints to empty-zones.
Check that DNS64 appropriately modifies the contents if configured.January 2021 (9.11.27, 9.11.27-S1, 9.16.11, 9.16.11-S1, 9.17.9)https://gitlab.isc.org/isc-projects/kea/-/issues/432for bad formed cmds sent over http class-cmds sometimes return dictionary in...2020-12-14T10:43:26ZMichal Nowikowskifor bad formed cmds sent over http class-cmds sometimes return dictionary instead of listthis in case of e.g.:
```json
{"command": "class-add", "arguments": {"client-classes": [{"name": "ipxe"}]}, "extra_arg": {}}
```this in case of e.g.:
```json
{"command": "class-add", "arguments": {"client-classes": [{"name": "ipxe"}]}, "extra_arg": {}}
```kea1.9.3Marcin SiodelskiMarcin Siodelskihttps://gitlab.isc.org/isc-projects/kea/-/issues/164empty test in src/bin/dhcp6/tests/dhcp6_process_tests.sh2020-12-14T09:11:51ZWlodzimierz Wencelempty test in src/bin/dhcp6/tests/dhcp6_process_tests.shwhile running unit tests dhcp6_process_tests.sh is executing empty test:
```
START TEST dhcpv6.version
PASSED dhcpv6.version
```
line 487 in dhcp6_process_tests.sh (dhcp6_process_tests.sh.in) is declaring test: version_test "dhcpv6.versi...while running unit tests dhcp6_process_tests.sh is executing empty test:
```
START TEST dhcpv6.version
PASSED dhcpv6.version
```
line 487 in dhcp6_process_tests.sh (dhcp6_process_tests.sh.in) is declaring test: version_test "dhcpv6.version" but there is no function that can be executed.kea1.9.3Andrei Pavelandrei@isc.orgAndrei Pavelandrei@isc.orghttps://gitlab.isc.org/isc-projects/kea/-/issues/1605bump lib version for kea 1.9.32020-12-11T20:43:29ZRazvan Becheriubump lib version for kea 1.9.3bump lib version for kea 1.8.2bump lib version for kea 1.8.2kea1.9.3Razvan BecheriuRazvan Becheriuhttps://gitlab.isc.org/isc-projects/kea/-/issues/692whitespace in db password doesn't work and gets logged2020-12-11T20:12:01ZGhost Userwhitespace in db password doesn't work and gets logged**Describe the bug**
If a (postgresql, possibly other db) password specified in kea-dhcp4.conf contains whitespace, it causes the config processing to fail and the password to be logged unredacted.
**To Reproduce**
Steps to reproduce ...**Describe the bug**
If a (postgresql, possibly other db) password specified in kea-dhcp4.conf contains whitespace, it causes the config processing to fail and the password to be logged unredacted.
**To Reproduce**
Steps to reproduce the behavior:
1. Configure a database user for the kea database with a password containing whitespace - e.g. "foo bar":
2. Run Kea dhcpv4 with the following hosts-database in the config:
`"hosts-database": {
"type": "postgresql",
"host": "localhost",
"name": "kea",
"user": "kea",
"password": "foo bar"
}`
3. Examine logs, find errors like these:
ERROR [kea-dhcp4.database] DATABASE_INVALID_ACCESS invalid database access string: host=localhost name=kea password=foo bar type=postgresql user=kea universe=4
ERROR [kea-dhcp4.dhcp4/17119] DHCP4_CONFIG_LOAD_FAIL configuration error using file: /etc/kea/kea-dhcp4.conf, reason: Unable to open database: Cannot parse bar, expected format is name=value
**Expected behavior**
The server should start up just as it does when both the password configured for the database user and the password
**Environment:**
- Kea version: 1.5.0, compiled myself from the version released in Debian Sid
- OS: Debian Stretch
- Compiled as determined by the Debian Sid package, at least with postgresql support.
**Additional Information**
I think the problem happens because [DbAccessParser::getDbAccessString() const](https://gitlab.isc.org/isc-projects/kea/blob/master/src/lib/database/dbaccess_parser.cc#L232) does not do anything like quoting when serializing the values of the ParameterMap, so when the string gets reparsed confusion ensues. As hinted by [this comment in process::ConfigControlParser::parse(...)](https://gitlab.isc.org/isc-projects/kea/blob/master/src/lib/process/config_ctl_parser.cc#L39), perhaps it's not necessary to serialize the ParameterMap into a string at all.kea1.9.3Marcin SiodelskiMarcin Siodelski