Bug#516394: removal of djbdns ?
On Sun, Aug 02, 2020 at 10:28:04PM +0200, Moritz Mühlenhoff wrote: > Hi Peter, > > On Mon, Jul 27, 2020 at 05:20:23PM +0300, Peter Pentchev wrote: > > Now... related to that. I am not sure whether Moritz Muehlenhoff, when > > reopening this bug, was aware of the fact that Dmitry Bogatov included > > two patches from Jeff King that address the cache poisoning attack - > > and actually, the patches were mentioned in this bug log by Matija Nalis > > back in 2010. Moritz, is it possible that you had missed the inclusion > > of these two patches, or do you believe that they, by themselves, are > > still not enough to address this problem? If so, that would indeed be > > kind of unfortunate, since it is my impression that these particular > > patches are considered the best way to handle this among users of > > Prof. Bernstein's software. > > I only reopened the bug since there was a discussion on debian-devel about > the fact that bugs in removed-and-then-reintroduced packages don't get > automatically reopened and remembered that long-standing bug. The changelog > made by Dmitry Bogatov doesn't mention it either. If that specific bug is > believed to be fixed by these two patches, then I trust you on that. So > feel free to mark the bug as closed in 1:1.05-10, then. Thanks for your reply! Yes, I think I will do that, since IMHO the problem is indeed mitigated as much as possible by these patches. > The fact that djbdns has no active upstream is a different concern, though, > especially in the wake of the whole qmail disaster. Following it, Georgi > Guninski > raised a few issues on oss-security e.g. > (https://www.openwall.com/lists/oss-security/2020/06/01/1) and without an > active upstream noone ever addressed or investigated them. Ah, I wasn't aware of this thread, thanks for pointing it out! I will reply to his last message, since one of the problems is nonexistent and the other one is not really exploitable except in a very narrow, specific case (the "make a CDB file" routines are only used by the tools that create the tinydns/axfrdns/rbldns data files, they are never invoked with any network input, so the only problem scenario would be somebody, e.g. a hosting provider, using automated tools to create a CDB file that is very, very, very close to the 4 GB limit, and not noticing that the file is very close to the (well-documented) limit in time. But, yeah, I may look at other uses of alloc() in the djbdns source code... and I do kind of get your point in general, not about this specific case. I think that Prof. Bernstein considers djbdns to be feature-complete and bug-free, at least in his own understanding of both these terms; I think that if any really serious problems should appear, he will comment on them. Unfortunately, this leaves the maintainers of djbdns in the various packaging systems with the responsibility to evaluate and mitigate things that he does not really consider to be really serious problems, you are right about that. Well, all I can say is that I have really liked djbdns ever since it first came out (I was already using qmail, daemontools, and other pieces of Prof. Bernstein's software; I have since moved on to replacements for most of them, but I still find the djbdns command-line query tools easier to use in most cases, usually only falling back to a fully-fledged hundred-character dig command line), and I will try my best to keep it usable in Debian. Again, thanks for your work on this bug, both before and now, and sorry that this reply came out a bit longer than I intended... G'luck, Peter -- Peter Pentchev r...@ringlet.net r...@debian.org p...@storpool.com PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13 signature.asc Description: PGP signature
Bug#516394: removal of djbdns ?
Hi Peter, On Mon, Jul 27, 2020 at 05:20:23PM +0300, Peter Pentchev wrote: > Now... related to that. I am not sure whether Moritz Muehlenhoff, when > reopening this bug, was aware of the fact that Dmitry Bogatov included > two patches from Jeff King that address the cache poisoning attack - > and actually, the patches were mentioned in this bug log by Matija Nalis > back in 2010. Moritz, is it possible that you had missed the inclusion > of these two patches, or do you believe that they, by themselves, are > still not enough to address this problem? If so, that would indeed be > kind of unfortunate, since it is my impression that these particular > patches are considered the best way to handle this among users of > Prof. Bernstein's software. I only reopened the bug since there was a discussion on debian-devel about the fact that bugs in removed-and-then-reintroduced packages don't get automatically reopened and remembered that long-standing bug. The changelog made by Dmitry Bogatov doesn't mention it either. If that specific bug is believed to be fixed by these two patches, then I trust you on that. So feel free to mark the bug as closed in 1:1.05-10, then. The fact that djbdns has no active upstream is a different concern, though, especially in the wake of the whole qmail disaster. Following it, Georgi Guninski raised a few issues on oss-security e.g. (https://www.openwall.com/lists/oss-security/2020/06/01/1) and without an active upstream noone ever addressed or investigated them. Cheers, Moritz
Bug#516394: removal of djbdns ?
On Mon, Jun 08, 2020 at 07:44:22PM +0200, Matija Nalis wrote: > Hi, > > I see djbdns is removed from testing, due to unarchiving of > critical bug #516394 > > However, as source package djbdns 1:1.05-11 builds several binary > packages (axfrdns, djbdns-conf, djbdns-utils, rbldns, tinydns, > walldns) and the bug is only in (if not patched) dnscache, > would other packages reenter testing and later new stable Debian? Hi, I just adopted the djbdns package; the 1:1.05-12 upload with a couple of packaging fixes should hit unstable in the mirror sync (it has already been built on most architectures; I'll drop the lsof build dependency in the next upload so that it builds on even more). Apropos, let me express my thanks to Dmitry Bogatov for the large overhaul in 1:1.05-10: bringing the Debian packaging up to date and incorporating some bugfixes from other packaging systems. Now... related to that. I am not sure whether Moritz Muehlenhoff, when reopening this bug, was aware of the fact that Dmitry Bogatov included two patches from Jeff King that address the cache poisoning attack - and actually, the patches were mentioned in this bug log by Matija Nalis back in 2010. Moritz, is it possible that you had missed the inclusion of these two patches, or do you believe that they, by themselves, are still not enough to address this problem? If so, that would indeed be kind of unfortunate, since it is my impression that these particular patches are considered the best way to handle this among users of Prof. Bernstein's software. Of course, I do not intend to argue with the Security Team - I only have the utmost respect and gratitude for everything you people do for Debian! So if it is still your collective stated position that Jeff King's patches, applied to the djbdns package in Debian as debian/patches/0007-dnscache-merge-similar-outgoing-udp-packets.patch and debian/patches/0008-Cache-SOA-records.patch, are not enough, then I guess I may have to look for some other way to manage the situation, possibly breaking dnscache off into its own source package to allow the rest to eventually migrate to testing. I am late in coming to this discussion, so let me express my thanks to everyone who has spoken their mind in good faith in the bug log. Here's hoping we find some way to move forward :) G'luck, Peter -- Peter Pentchev r...@ringlet.net r...@debian.org p...@storpool.com PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13 signature.asc Description: PGP signature
Bug#516394: removal of djbdns ?
Hi, I see djbdns is removed from testing, due to unarchiving of critical bug #516394 However, as source package djbdns 1:1.05-11 builds several binary packages (axfrdns, djbdns-conf, djbdns-utils, rbldns, tinydns, walldns) and the bug is only in (if not patched) dnscache, would other packages reenter testing and later new stable Debian? I don't particularly care about dnscache, but use other parts of djbdns (tinydns, axfrdns, djbdns-utils...) often. I don't know if only some binary packages sharing same source package can be blocked from entering testing, or how this should reasonably be handled so other binary packages remain in Debian (lowering severity to important, as much of the binaries are non-affected? patching dnscache with provided patches?) I am not DD/DM, but have some experience with creating Debian packages, so am willing to help if needed. Thanks! -- Opinions above are GNU-copylefted.
