Upstream here. I should probably summarize the security issues post 2.0.13; MaraDNS is the authoritative server and Deadwood is the recursive server:
- A theoretical issue with the cryptographic code which doesn’t affect gcc and clang compiles of Deadwood. - An issue where a clever attacker could had kept a record in the cache longer than desired in a fully recursive instance of Deadwood. - An issue where a clever attack could make Deadwood perform around 500 queries to resolve a given name, if they can control the query and responses Deadwood gets. In the fix, that number was reduced to 83. None of these are serious security issues; I would be comfortable using a non-Recursive instance of MaraDNS 2.0.13 on a public network, but they are “it’s probably worth updating” security issues. I should point out that MaraDNS 3 is fully compatible with MaraDNS 2 configuration files and the number jump was done to keep Deadwood’s and MaraDNS’s version numbers in sync. In terms of the upgrade, there are two branches to consider: - The very stable 3.4 branch, where the fixes are by and large security and other serious fixes. This branch, which was dormant for about three years, recently had a flurry of updates for minor security and Y2038 fixes. [1] The majority of the updates are made as patches which can be applied to older versions, if Debian wants to take the “patch older software” route. My plan is to keep this branch dormant again unless another security issue comes up. In particular, this branch is generally *not* updated to fix resolution issues with the Deadwood recursive resolver, unless it’s something huge like amazon.com not resolving. - The less stable 3.5 branch. This is the continuous integration version of MaraDNS; features are added and there’s no “frozen” branch. Automated testing is done once a day whenever the Git tree changes and I frequently make new releases when a given Git checkout passes automated tests. Effort is made to keep older configuration files compatible, so we don’t get the situation where configuration files need to be revised to apply a security update. [1] Other stuff was changed too. I changed a bunch Makefiles and filenames in MaraDNS 3.4 so that it will compile with a mostly-POSIX compliant implementation of `make`; POSIX actually didn’t mandate `-` in make targets (it will in the next 202X POSIX release); I added min_ttl to Deadwood so it remains semi usable as a fully recursive DNS server on the modern Internet. On Mon, Nov 21, 2022 at 5:03 AM Moritz Muehlenhoff <j...@debian.org> wrote: > > Source: maradns > Version: 2.0.13-1.4 > Severity: serious > > The last maintainer upload was in 2015 and the version currently in the > archive is way behind current upstream releases (which is at 3.4.07), > we have plenty of maintained DNS servers, keep it out of testing ( > and if noone picks it up, remove it from the archive). >
