tags 516394 patch thanks
Hi Gerrit, I'd appreciate very much if you could spare this update some time. Thanks. I see in http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=516394#10 that you have a problem with http://www.your.org/dnscache/0001-dnscache-merge-similar-outgoing-queries.patch due to issues at http://thread.gmane.org/gmane.network.djbdns/13705/focus=13868 Are you aware of new (fixed) version of the patch at: http://marc.info/?l=djbdns&m=123859517723684&w=1 It should fix mentioned concerns, and it also allows one to "shut down" the patch at runtime simply by not setting MERGEQUERIES environment variable (which should probably set by default to keep Security team happy). Now, I completely agree with you and DJB that the issue at hand is actually design error in DNS protocol itself, and that being able to poison in few minutes instead of in few hours is not really such a tremendous difference that djbdns should be excluded from Debian Stable, and BIND and all other DNS proxy servers shouldn't (which I wildly guess is the root of your conflict with security team). That said, while I agree with DJB that this is fundamental DNS design issue, I do not see Debian Security Team removing all DNS proxy related packages (nor would that accomplish anything security-wise), not do I see the DNS being redesigned from scratch and redeployed all over the world before new Debian Stable is out (not even if it took longer than Sarge!) While I completely agree with DJB that DNS is fundamentally broken, I just don't buy into such fatalist and nihilist approach as "it's broken and we're all doomed". Now, if there is a ready, deployable right now and *interoperable right now* fix (which there isn't AFAIK), by all means let's use it; but until such a beast is available, we should strive to achieve BCP, even if it just adds "some speed bumps". Otherwise, the evolution (or at least the Debian Security Team) will wipe out the weakest (being unpatched dnscache ATM, after all those years of it being the best). However, even without knowing about your discussions with security team (which seem to have gone sour, which make me sad), I might probably agree with them that solution of lowering MAXUDP to just 20 which you propose in: in http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=516394#36 is not very good solution (even if not for their reasons!) - while it will happily work for SOHO, it would make a package hardly usable on most sites much bigger than that. (I've run dnscache on mid-sized sites to low-end ISP (about 20k users), and more than once did I have to raise the limit from 200 upwards). But I can also see why you wouldn't like to "poison" the dnscache code with mostly untested in the wild patches (especially given whole djbdns/dbndns distinction). However, I would very much like to know your stand on that, given the above (some of it new?) information. As I see, the possible options are (from worst to best IMHO): a) nothing is done -> djbdns/dbndns drops from debian stable completely b) dnscache is removed from the package; this "fixes" this bug and allows at least other parts of the package to enter debian stable (tinydns, walldns, rbldns, utils, ...) c) new patch at http://marc.info/?l=djbdns&m=123859517723684&w=1 is applied, with default MERGEQUERIES set in dnscache-run package. I assume that one would make security team happy, and since everyone can disable the patch if they don't trust it, it might make you happy enough to. You could even popup the dialog on upgrade to let the user know or even choose their options. Alternatively, Francis patch at http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=516394#106 is shown good enough to fix the issue and we use that. Gerrit, I know you're probably frustrated with this issue, but I'd really appreciate your take on this. Is there anything the rest of community can do? Do you see any other options? I guess (a) will happen by default if nothing is done, and that seems like the worst option for the users of djbdns to me... -- Opinions above are GNU-copylefted. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
