Create new changelog and include it in the documentation. Include the
previous CHANGES as plain text without any markup.
(cherry picked from commit e9b6031e0c)
Add an option which can be used to put short commit sha at the end of
each commit subject line in the generated changelog.
(cherry picked from commit c2b23fa2de)
Given our workflow, this could easily lead to misattribution. It's also
not an actionable information and it can be found in the MR / git log
instead.
(cherry picked from commit a8258d1c53)
The project hasn't seen any new development/changes since 2018 and it
seems unlikely we'd be able to get any changes into the upstream. Since
it's isolated into a single file and its task is fairly straighforward,
pull the code into our own repository and maintain it here as needed.
This also makes it easier to make any changes that are specific to our
project.
(cherry picked from commit 63247d8a73)
Stale repositories cause issue on installation in the docs:pdf CI job:
E: Failed to fetch http://deb.debian.org/debian/pool/main/s/systemd/libsystemd-shared_252.22-1%7edeb12u1_amd64.deb 404 Not Found [IP: 2a04:4e42:78::644 80]
E: Unable to fetch some archives, maybe run apt-get update or try with --fix-missing?
(cherry picked from commit 211a514dbd5d122a37ddb29f6db63edc86af73b7)
As opposed to the main branch (where the SIG(0) was changed), it has
been removed from the maintenance branches. Use a different changes
number to indicate there was a different solution of the issue.
This commit ensures that we restart reading only when all DNS data in
the input buffer is processed so the we will not get into the
situation when the buffer is overrun.
When sending fails, the ns__client_request() would not reset the
connection and continue as nothing is happening. This comes from the
model that we don't care about failed UDP sends because datagrams are
unreliable anyway, but it greatly affects TCP connections with
keep-alive.
The worst case scenario is as follows:
1. the 3-way TCP handshake gets completed
2. the libuv calls the "uv_connection_cb" callback
3. the TCP connection gets queue because of the tcp-clients quota
4. the TCP client sends as many DNS messages as the buffers allow
5. the TCP connection gets dropped by the client due to the timeout
6. the TCP connection gets accepted by the server
7. the data already sent by the client gets read
8. all sending fails immediately because the TCP connection is dead
9. we consume all the data in the buffer in a very tight loop
As it doesn't make sense to trying to process more data on the TCP
connection when the sending is failing, drop the connection immediately
on the first sending error.
(cherry picked from commit bf9fd2a6ff)
Be more aggressive when throttling the reading - when we can't send the
outgoing TCP synchronously with uv_try_write(), we start throttling the
reading immediately instead of waiting for the send buffers to fill up.
This should not affect behaved clients that read the data from the TCP
on the other end.
(cherry picked from commit bc3e713317)
Instead of outright refusing to add new RR types to the cache, be a bit
smarter:
1. If the new header type is in our priority list, we always add either
positive or negative entry at the beginning of the list.
2. If the new header type is negative entry, and we are over the limit,
we mark it as ancient immediately, so it gets evicted from the cache
as soon as possible.
3. Otherwise add the new header after the priority headers (or at the
head of the list).
4. If we are over the limit, evict the last entry on the normal header
list.
(cherry picked from commit 57cd34441a)
Instead of relying on a specific order of the RR types in the databases
pick the first RR type as returned from the cache.
(cherry picked from commit 58f660cf2b)
Add HTTPS, SVCB, SRV, PTR, NAPTR, DNSKEY and TXT records to the list of
the priority types that are put at the beginning of the slabheader list
for faster access and to avoid eviction when there are more types than
the max-types-per-name limit.
(cherry picked from commit b27c6bcce8)
This commit ensures that socket objects use smaller sizes for its
internal requests and handles pools. That prevents a memory allocator
from thrashing.
When a peer is not reading the data we are sending it was for the TLS
DNS code to end up in a situation when it would indefinitely
reschedule send requests, effectively turning the 'uv_loop' into a
busy loop that would consume CPU cycles in endless efforts to send
outgoing data.
The main reason for that was only one send buffer dedicated for sends:
the code would re-queue sends until it is empty - that would never
happen when the remote side is not reading data.
That seems like an omission from the older day of the Network Manager
as it is quiet simple to make the code use multiple buffers for
sends. That ultimately breaks the cycle of futile send request
rescheduling.
As a side effect, this commit also gets rid of one memory copying on a
hot path.
Due to omission it was possible to un-throttle a TCP connection
previously throttled due to the peer not reading back data we are
sending.
In particular, that affected DoH code, but it could also affect other
transports (the current or future ones) that pause/resume reading
according to its internal state.
(cherry picked from commit d228aa8bbb944fbd04baf22d151fde5c33561e26)
Clear qctx->zversion when clearing qctx->zrdataset et al in
lib/ns/query.c:qctx_freedata. The uncleared pointer could lead to
an assertion failure if zone data needed to be re-saved which could
happen with stale data support enabled.
(cherry picked from commit 179fb3532ab8d4898ab070b2db54c0ce872ef709)
Test that SIG(0) signer is NOT sent to the external socket for
authorization. It MUST NOT be considered a valid signature by
any chance.
Also check that the signer's name does not appear in authsock.pl
output.
Nicki Křížek
Michal NowakandNicki Křížek
Artem BoldarievandOndřej Surý
Matthijs MekkingandNicki Křížek
Mark AndrewsandNicki Křížek
Petr ŠpačekandNicki Křížek
Aram SargsyanandNicki Křížek