The version number for the XML statistics channel was not incremented
correctly after removal of isc_socket code in
a55589f881bc4e4c1099e50b6d4ce84ffc7b5ba3, and the JSON version number
was not incremented at all.
Check to see whether there are outstanding requests in the
httpd receive buffer after sending the response, and if so,
process them.
Test that pipelined requests are handled by sending multiple
minimal HTTP/1.1 using netcat (nc) and checking that we get
back the same number of responses.
Remember the amount of space consumed by the HTTP headers, then
move any trailing data to the start of the httpd->recvbuf once
we have finished processing the request.
if an incoming HTTP request is incomplete, but nothing else is clearly
wrong with it, the stats channel continues reading to see if there's
more coming. the buffer length was not being processed correctly in
this case. also, the server state was not reset correctly when the
request was complete, so that subsequent requests could be appended to
the first buffer instead of being treated as new.
in addition fixing the above problems, this commit also increases the
size of the httpd request buffer from 1024 to 4096, because some
browsers send a lot of headers.
A typo introduced in f3f1cab05e05c9bdd5da91f3ab159ec6658ec7f4 prevents
execution of the dns_name_copy-with-result.spatch. The replacement
should end with semicolon not a colon:
plus: parse error:
File "cocci/dns_name_copy-with-result.spatch", line 28, column 23, charpos = 421
around = ':',
whole content = + dns_name_copy(E1, E2):
1) if 'key->external' is set we just need to call
dst__privstruct_writefile
2) the cleanup of 'bufs' was incorrect as 'i' doesn't reflect the
the current index into 'bufs'. Use a simple for loop.
This review was triggered by Coverity reporting a buffer overrun
on 'bufs'.
'dh' was being assigned to key->keydata.dh too soon which could
result in a memory leak on error. Moved the assignement of
key->keydata.dh until after dh was correct.
Coverity was reporting dead code on the error path cleaning up 'dh'
which triggered this review.
'make dist' omits lib/dns/tests/comparekeys/ (added in
7101afa23cfc7cd005aeeb00802481094a0b9cf5) from release tarball it
creates which makes the unit:gcc:tarball CI job permanently fail in the
dst unit test.
Be less strict regarding "tls" statements in the configuration file by allowing both "key-file" and "cert-file" be omitted
See merge request isc-projects/bind9!5546
In the 9.17.19 release "tls" statements verification code was
added. The code was too strict and assumed that every such a statement
should have both "cert-file" and "key-file" specified. This turned out
to be a regression, as in some cases we plan to use the "tls"
statement to specify TLS connection parameters.
This commit fixes this behaviour; now a "tls" statement should either
have both "cert-file" and "key-file" specified, or both should be
omitted.
It was used only as guard against unused variable declaration, but the
surrounding code depends on strtok_r being defined unconditionally, so
there is no point in guarding a variable.
Glibc documentation suggests it is obsolete anyway and e.g. Meson build
system decided to ignore it. It seems to be required only by old
Solaris compiler and OpenIndiana uses gcc.
It's major PITA trying to guess what exactly clang-format has changed,
so how CI stores patch file with changes which can be applied locally if
needed.
PyLint 2.11 reports a new warning, C0209 (consider-using-f-string).
Since f-strings are only available in Python 3.6+, existing scripts
cannot be updated to use this feature just yet because they would stop
working with older Python versions. Instead, disable PyLint warning
C0209 for the time being. Sort all disabled warnings in .pylintrc.
GL #2308 was originally referenced by CHANGES entry 5727. However, the
corresponding code change turned out to be flawed and had to be reverted
in BIND 9.17.19, causing CHANGES entry 5727 to be turned into a
placeholder on the release branch.
Commit 63145fb1d328eb66f9c786d2273bc2e3f6a3ecf5 subsequently addressed
the flaw, so the fix for GL #2308 will be included in BIND 9.17.20.
Move the relevant CHANGES entry to reflect that.
Previously, when lame cache would be disabled by setting lame-ttl to 0,
it would also disable lame answer detection. In this commit, we enable
the lame response detection even when the lame cache is disabled. This
enables stopping answer processing early rather than going through the
whole answer processing flow.
The lame-ttl cache is implemented in ADB as per-server locked
linked-list "indexed" with <qname,qtype>. This list has to be walked
every time there's a new query or new record added into the lame cache.
Determined attacker can use this to degrade performance of the resolver.
Resolver testing has shown that disabling the lame cache has little
impact on the resolver performance and it's a minimal viable defense
against this kind of attack.
