Bug#1024561: Unmaintained, keep out of stable

[Sam Trenholme]

[1] RFC8482 responds to ANY in such as way as to not break Qmail

On Sat, Nov 26, 2022 at 10:34 AM Sam Trenholme  wrote:
>
> Upstream here again.  I have released MaraDNS 3.5.0030 and 3.4.09 with
> a security update: MaraDNS now fully supports RFC8482, which means
> MaraDNS no longer supports ANY records. [1] While MaraDNS does not
> have long packet support, this removes one possible denial of service
> amplification path.
>
> If someone can not step up to plate to maintain MaraDNS for Debian, we
> should deprecate and eventually remove the package.
>
> I may end up making my own .deb files for MaraDNS.
>
> -- Sam
>
> On Mon, Nov 21, 2022 at 5:03 AM Moritz Muehlenhoff  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).
> >

Bug#1024561: Unmaintained, keep out of stable

[Sam Trenholme]

Upstream here again.  I have released MaraDNS 3.5.0030 and 3.4.09 with
a security update: MaraDNS now fully supports RFC8482, which means
MaraDNS no longer supports ANY records. [1] While MaraDNS does not
have long packet support, this removes one possible denial of service
amplification path.

If someone can not step up to plate to maintain MaraDNS for Debian, we
should deprecate and eventually remove the package.

I may end up making my own .deb files for MaraDNS.

-- Sam

On Mon, Nov 21, 2022 at 5:03 AM Moritz Muehlenhoff  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).
>

Bug#1024561: Unmaintained, keep out of stable

[Sam Trenholme]

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  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).
>

Bug#505381: genisoimage: writes blank sectors

[Sam Trenholme]

OK, some updates for 2021:

* genisoimage is officially marked "abandoned" and should not be used 
(time stamps will start break come 2028; I've fixed the bug but there's 
no genisoimage maintainer to update the program with the fix).  See 
https://wiki.debian.org/genisoimage for end-of-life notice


* As per that Wiki page, the official answer is to use xorrisofs, which 
yes has fixed (or never had) this "blank sector" bug


* I have made my own fork of genisoimage, iso9660, which fixes this bug 
and the bug with post-2027 timestamps: https://github.com/samboy/iso9660


- Sam


This behavior (or one very similar to it) appears to still be present,
five and a half years later. The patch still appears to apply (albeit
with considerable a offset) against current upstream SVN.

I have not managed to find any indication of what the reason for adding
these blank sectors is supposed to be. The code in question appears to
date all the way back to the original import of mkisofs into Subversion,
so there's no help there.

Any chance of either getting this patch applied, or at least figuring
out a reason why it would be a bad idea?

>
>

Bug#990468: genisoimage: Bad time stamps for post-2027 files

[Sam Trenholme]

Package: genisoimage
Version: 9:1.1.11-3+b2

Description of bug: .iso files generated with genisoimage will have
incorrect timestamps for files created on or after January 1, 2028

Steps to reproduce:

tar xvJf geniso-Y2076-test.tar.xz
# Please ignore timestamp in future warnings
genisoimage -J -V "test" -o test.iso geniso-Y2076-test/

Expected results:

The timestamps in the file test.iso will be between 5:03 and 5:05 am
(local time) for years between 2021 and 2076.

Actual results:

Some timestamp will have a different time because the
time zone value is invalid.

How to fix:

Edit the file genisoimage.c so that the function iso9660_date() does
not generate bad timestamps starting on January 1, 2028.

Here is a fixed version of the file (also, I made sure to have
reasonable values for timestamps for files dated before January 1,
1900 or after December 31, 2155):

int
iso9660_date(char *result, time_t crtime)
{
struct tm   *local;
struct tm   *gmt;
int year, yday, hour, minute, second, zone;

local = localtime();
result[0] = year = local->tm_year;
result[1] = local->tm_mon + 1;
result[2] = local->tm_mday;
yday = local->tm_yday;
result[3] = hour = local->tm_hour;
result[4] = minute = local->tm_min;
result[5] = second = local->tm_sec;

/* Sam Trenholme's notes: The following code has been updated to be
 * Y2028 compliant.  That is *not* a typo: Year twenty-*twenty*eight
 * (**not 2038!**).
 * In other words, result[6] (the time zone) had invalid values for
 * files created on or after January 1, 2028.
 */

/* First of all, the 9660 spec only allows timestamps between
 * January 1, 1900 and December 31, 2155.  So, handle timestamps
 * outside that spec by giving out timestamps at the end of the
 * spec.  It is unknown here in 2021 whether or not 2155 will
 * have a leap second; I will assume programmers are smart enough
 * to not have things crash if we have a leap second. */
if(year < 0) {
/* January 1, 1900 00:00:00 GMT */
result[0] = 0;
result[1] = 1;
result[2] = 1;
result[3] = 0;
result[4] = 0;
result[5] = 0;
result[6] = 0; /* Time zone */
return 0;
} else if(year > 255) {
/* December 31, 2155, 23:59:60 GMT */
result[0] = 255;
result[1] = 12;
result[2] = 31;
result[3] = 23;
result[4] = 59;
result[5] = 60;
result[6] = 0; /* Time zone */
return 0;
}

/* I have no idea why POSIX does not have tm_gmtoff.  Since it
 * doesn't, we have to calculate it ourselves. */
gmt = gmtime(); /* Zaps local, be careful */

zone = 0;

/* We will never be more than one day off between GMT and local
 * time.  That in mind, if the year is different, we are one day
 * behind or ahead.  Otherwise, if the day is different, it will
 * always be a one day difference. */
if(gmt->tm_year < year) {
zone = 86400; /* 24 hours in seconds */
} else if(gmt->tm_year > year) {
zone = -86400;
} else if(gmt->tm_yday < yday) {
zone = 86400;
} else if(gmt->tm_yday > yday) {
zone = -86400;
}

/* Now that we account for different days, account for different
 * hours, minutes, and seconds. */
zone += (hour - gmt->tm_hour) * 3600;
zone += (minute - gmt->tm_min) * 60;
zone += second - gmt->tm_sec;
result[6] = zone / 900; /* Every 15 minutes in 9660 spec */

return (0);
}

Additional notes:

File source code which uses 100% GPLv2 code and compiles and works in
Ubuntu 20.04 (probably also Debian) is at
https://github.com/samboy/9660img

Another comment:

I know there have been issues with the original upstream version of
the code possibly being linked to CDDL licensed code. Has anyone
attempted to contact Eric Youngdale and see if he’s willing to
dual-license the original mkisofs / cdrkit package to also have a CDDL
license so we can resolve the licensing dispute and have a version
directly derived from the version still maintained by the primary
mkisofs maintainer?


geniso-Y2076-test.tar.xz
Description: Binary data

Bug#936992: Upstream here: Please close this bug

[Sam Trenholme]

I have gone to the bother of converting bind2csv2.py to be a python2 and
python3 polyglot. Keep in mind that this script does not work with a good
number of real-world BIND zonefiles: But it will now run in python3 the
same way it runs in python2 (converting a strict subset of BIND zone files).

This updated bind2csv2.py file is currently only in GitHub, at this
location:

https://raw.githubusercontent.com/samboy/MaraDNS/master/tools/bind2csv2.py

For your convenience, this will close the following bug:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=936992

As an aside, the current stable version of MaraDNS is 3.4.01, and I will
not update bind2csv2.py in the stable release until I get a chance to
update how the tarball is made; one thing I plan on doing is making the Git
version of MaraDNS the one source of truth from which all tarballs are
created, and set up some continuous integration scripts so I can go from
the Git tree to source code tarballs in one command, and from source code
tarballs to Windows binaries from another single command run in Windows +
mingw/msys.  But that will happen in the future.

For now, again, the solution is not to remove MaraDNS from Debian, but to
find someone willing to maintain the Debian package. But,  open source
economics being what it is, since there’s no money on the table, that’s not
going to happen in the real world. Did I mention that there’s a theoretical
security issue in MaraDNS 2.0.13? I’ve fixed it well over a year ago.

Up to date information on MaraDNS’s security is available at
https://maradns.samiam.org/security.html

On Sat, Nov 2, 2019 at 6:54 AM Sam Trenholme  wrote:

> Upstream here: Please close this bug.
>
> One can close this bug by removing the Python2 dependency.
>
> MaraDNS does not use any Python, neither Python2, nor Python3, to build
> the code.
>
> MaraDNS does not use any Python to install the code.
>
> MaraDNS does not use any Python to run the authoritative daemon, nor the
> recursive daemon, nor the DNS-over-TCP daemon, nor the tool for making
> recursive DNS queries.
>
> Python is *only* used for the bind2csv2.py tool which converts Bind zone
> files in to MaraDNS zone files. One can safely remove this tool without
> affecting MaraDNS’s functionality.
>
> Thank you.
>

Bug#936992: Upstream here: Please close this bug

[Sam Trenholme]

Upstream here: Please close this bug.

One can close this bug by removing the Python2 dependency.

MaraDNS does not use any Python, neither Python2, nor Python3, to build the
code.

MaraDNS does not use any Python to install the code.

MaraDNS does not use any Python to run the authoritative daemon, nor the
recursive daemon, nor the DNS-over-TCP daemon, nor the tool for making
recursive DNS queries.

Python is *only* used for the bind2csv2.py tool which converts Bind zone
files in to MaraDNS zone files. One can safely remove this tool without
affecting MaraDNS’s functionality.

Thank you.

Bug#861910: maradns-deadwood: deadwood is labeled stable by upstream, how about a full package?

[Sam Trenholme]

To ask for better MX record handling in Deadwood is a feature request,
not a bug report. And upstream’s answer is: I’m not going to do that.
Most people should be using their ISPs mail hub to send mail, not a
small virtual server.

The nice thing about open source is that Andreas (or anyone else) is
free to update Deadwood to have better MX support if this is something
which scratches his itch (he can fix the issues with out-of-bailiwick
CNAME record handling while he’s still inspired to do a bunch of work
for free) — but that’s not my itch.

Deadwood’s big advantage of dnamasq is that it allows stuff like “use
slow in house DNS servers to resolve hostname.example.com, but use
8.8.8.8/4.2.2.1/whatever to resolve anything anything else” in a
configuration file (dnsmasq handles that with a special “-S” flag).

— Sam

On Sat, May 6, 2017 at 9:09 AM, Andreas Metzler  wrote:
> On 2017-05-05 Andreas Metzler  wrote:
>> Hello,
>
>> deadwood was released as stable by upstream. However the Debian package
>> only provides a bare-bone binary without infrastructure
>> (init-script/systemd support files). While the package description
>> documents this no reason is given why.
>
> Hello,
>
> I think I have found a reason for not using deadwood. In short I have
> the feeling that it is not optimized for the use-case where it might be
> useful. :-(
>
> I wanted to use deadwood on a vserver with limited resources, handling
> e-mail an WWW, and deadwood seemed to match the requirements:
> * small/tiny
> * recursive
> * caching
>
> However according to deadwood(1) it would perform poorly there since MX
> handling is - eh - suboptimal:
> | please keep in mind that Deadwood is optimized to be used for web
> | surfing, not as a DNS server for a mail hub. In particular, the IPs
> | for MX records are removed from Deadwood's replies and Deadwood needs
> | to perform additional DNS queries to get the IPs corresponding to MX
> | records
>
> OTOH for /web/ /surfing/ I would rather use dnsmasq. I do not see the
> requirement for recursive DNS there and the resources on desktop
> computers used for surfing are not strained, tinyness is not a
> requirement here.
>
> Anyway. Before discovering this I spent some time on packaging deadwood.
> Preliminary patch attached. (Before uploading I'd switch to a customized
> dwood3rc in debian/ instead of patching the upstream version.)
>
> cu Andreas
> --
> And so my quest for a dnscache replacement continued.

Bug#844121: CVE-2016-9300, CVE-2016-9301, and CVE-2016-9302 are *NOT* valid bug reports

[Sam Trenholme]

Thank you for verifying this is not a bug. I would rather have a false
bug report than have a real security issue out there that I’m not
aware of.

I should explain why the MaraDNS code is so messy and hard to follow:

Back in 2001, there was precisely one and only one open-source DNS
server: BIND. This was an issue, so there was a call to arms to have
another open source DNS server out there:
http://old.lwn.net/2001/0208/

That in mind, I quickly wrote up a DNS server; within two months I had
a usable authoritative server, and within a year I had a usable
recursive server. This rapid development came at a cost: The code
worked, was remarkably secure considering how quickly I wrote it, but
it was a mess to maintain. I had planned for years to rewrite MaraDNS,
and five years after the initial recursive server, I started a project
to rewrite the recursive code. My plan was to have a recursive server
within a year; while I had a usable caching server with cleaner code
within six months, it took me three years to make it a fully recursive
server.

My original plan was to rewrite the recursive component, than rewrite
the authoritative component. That never happened, for a number of
reasons, including the fact that DjbDNS became open-source after I
started MaraDNS 2.0’s recursive server, and NSD/Unbound came on to the
scene. With the excellent Knot DNS and Knot Resolver now also carrying
the torch for open source DNS servers, and with my life having a lot
less free time than I did a decade and a half ago when I started
MaraDNS, MaraDNS is in deep freeze maintenance mode.

I still take responsibility for security issues in the code I wrote a
long time ago, since there’s a contingent of users who feel MaraDNS is
more lightweight on “low end boxes” such as virtual machines with only
128 megs of memory (and are willing to give up DNSsec support to have
something that lightweight). But, beyond that, I don’t have time to
even fix things like resolution issues caused because the way DNS
servers handle out-of-bailiwick glue in CNAME records has changed
since 2001. Forget about adding DNSsec to MaraDNS.

Anyway, I do welcome security reports to MaraDNS and do take them very
seriously. There may not be a “packet of death” bug in the MaraDNS
codebase — João Antunes did a pretty through audit of the
authoritative codebase back in 2007 and probably would have found a
“packet of death” back then if there was one.

— Sam

On Mon, Dec 5, 2016 at 5:27 AM, Ondřej Surý <ond...@sury.org> wrote:
> Sam and others,
>
> I most deeply apologize, you are right in your assessment.
>
> I somehow missed the extra four additional sanity checks at the
> beginning of the getudp() function that seems to catch the error
> conditions on those input buffers.
>
> Cheers,
> --
> Ondřej Surý <ond...@sury.org>
> Knot DNS (https://www.knot-dns.cz/) – a high-performance DNS server
> Knot Resolver (https://www.knot-resolver.cz/) – secure, privacy-aware,
> fast DNS(SEC) resolver
> Vše pro chleba (https://vseprochleba.cz) – Mouky ze mlýna a potřeby pro
> pečení chleba všeho druhu
>
> On Sat, Dec 3, 2016, at 16:47, Sam Trenholme wrote:
>> CVE-2016-9300, CVE-2016-9301, and CVE-2016-9302 are *NOT* valid bug
>> reports.
>>
>> Here’s the deal: The reporter had to patch MaraDNS before he was able
>> to crash her.
>>
>> The patch, however, treats MaraDNS’ special buffer-overflow-resistant
>> “js_string” as if it were an ordinary string — but it’s not. Here’s
>> the offending code patched in to MaraDNS from the reporter’s “bug
>> report”:
>>
>> sock_num = read(0, incoming, 512);
>>
>> As per the man page for read:
>>
>> ssize_t read(int fd, void *buf, size_t count);
>>
>> DESCRIPTION
>>read()  attempts to read up to count bytes from file descriptor fd
>>into
>>the buffer starting at buf.
>>
>> However, incoming is not a raw string buffer: It’s a special js_string
>> object which MaraDNS uses to be buffer overflow resistant, as can be
>> seen here in server/MaraDNS.c:
>>
>> int main(int argc, char **argv) {
>>
>> js_string *mararc_loc = 0, *errors = 0,
>>   *bind_address = 0, *ipv6_bind_address = 0,
>>   *csv2_synthip_address = 0,
>>   *ipv4_bind_address = 0, *incoming = 0,
>>   *uncomp = 0, *verbstr = 0;
>>
>> The js_string structure (I guess I would call it an object here in
>> 2016) is defined in libs/JsStr.h:
>>
>> typedef struct {
>> unsigned char *string;   /* Actual physical string */
>> unsigned int unit_size;  /* The size of a single character in the
>> string */
>> unsigned int unit_count; /* The length of the string, in units */
>> un

Bug#844121: CVE-2016-9300, CVE-2016-9301, and CVE-2016-9302 are *NOT* valid bug reports

[Sam Trenholme]

CVE-2016-9300, CVE-2016-9301, and CVE-2016-9302 are *NOT* valid bug reports.

Here’s the deal: The reporter had to patch MaraDNS before he was able
to crash her.

The patch, however, treats MaraDNS’ special buffer-overflow-resistant
“js_string” as if it were an ordinary string — but it’s not. Here’s
the offending code patched in to MaraDNS from the reporter’s “bug
report”:

sock_num = read(0, incoming, 512);

As per the man page for read:

ssize_t read(int fd, void *buf, size_t count);

DESCRIPTION
   read()  attempts to read up to count bytes from file descriptor fd into
   the buffer starting at buf.

However, incoming is not a raw string buffer: It’s a special js_string
object which MaraDNS uses to be buffer overflow resistant, as can be
seen here in server/MaraDNS.c:

int main(int argc, char **argv) {

js_string *mararc_loc = 0, *errors = 0,
  *bind_address = 0, *ipv6_bind_address = 0,
  *csv2_synthip_address = 0,
  *ipv4_bind_address = 0, *incoming = 0,
  *uncomp = 0, *verbstr = 0;

The js_string structure (I guess I would call it an object here in
2016) is defined in libs/JsStr.h:

typedef struct {
unsigned char *string;   /* Actual physical string */
unsigned int unit_size;  /* The size of a single character in the string */
unsigned int unit_count; /* The length of the string, in units */
unsigned int max_count;  /* The maximum allowable size of the string,
   also in units */
int encoding;   /* The type of language/encoding the string is in */
int is_good;/* This is checked to make sure the data structure is
   sane */
} js_string;

Point being, if we patch MaraDNS to treat this structure as a raw
buffer instead of a structure, we will be able to crash MaraDNS — but
that doesn’t mean we have found a UDP packet of death which will crash
unpatched MaraDNS 2.0.13.

I appreciate that people are performing security research with
MaraDNS, and the fact that researchers need to resort to patching
MaraDNS before crashing her indicates that, a decade and a half later
MaraDNS is still a usable DNS server with a strong security record.

Bug#844121: Remote crash in MaraDNS 2.0.13

[Sam Trenholme]

This email concerns CVE-2016-9300, CVE-2016-9301, and CVE-2016-9302.

I have written a utility to send the packets that supposedly remotely crash
MaraDNS to MaraDNS via UDP. The packets do not crash MaraDNS when sent over
the network; I can only crash MaraDNS with the offending packets by using
the reporter’s patch to update MaraDNS to get DNS packets via standard
input, and only in my 64-bit Cygwin development environment.

I am closing this issue; I will open this again if someone can come up with
an actual "send this UDP packet and MaraDNS crashes" recipe. Please let me
know which OS and which processor architecture the crash happens on, but if
the OS is anything besides CentOS6 or the architecture anything besides x86
(32-bit) or amd_64/x86-64 (64-bit), I will not be able to address the
concern without a patch being provided.

Further discussion of this matter can be done by either replying to this
email, or by adding a note to https://github.com/samboy/MaraDNS/issues/33

Again, I will reopen this issue as a critical security issue if and only if
someone can reproduce this concern via an actual UDP packet sent to
MaraDNS. Please provide the source code of the program generating the
packet of death, or use the program I wrote to attempt to reproduce this
issue at
https://github.com/samboy/MaraDNS/blob/1dba9f49e9b6f788cf602695478edcb094a0cc06/sqa/sendpacket.c
(sqa/sendpacket.c if you clone the Github tree as of 2016-12-03).

Ondrej: If you were to provide a patch, or even a usable stack trace -- or
even just let me know on which distribution and architecture you're seeing
the issue (sorry, but I couldn't get a usable core file or stack trace in
Cygwin-64, and no crash at all in CentOS6-32bit) -- I will open up a GitHub
bug about the issue. I agree there is probably a bug in MaraDNS -- but I
will not treat this as an "all hands on deck" packet-of-death level
security bug until we can send an actual packet of death over UDP to kill
MaraDNS.

On Sat, Dec 3, 2016 at 6:04 AM, Sam Trenholme <mara...@gmail.com> wrote:

> Github bug: https://github.com/samboy/MaraDNS/issues/33
>
> Please go here to get the latest updates from upstream about this issue.
>
> On Sat, Dec 3, 2016 at 5:52 AM, Sam Trenholme <mara...@gmail.com> wrote:
>
>> Hello there,
>>
>> I have just become aware of this bug. Right now, I can reproduce the
>> crash in Cygwin 64-bit, but am unable to reproduce the crash in my 32-bit
>> CentOS6 development environment where I would actually be able to get a
>> full stack trace (which was not provided in the original bug report). Until
>> I can get a setup to reproduce the crashes in a manner which lets me have
>> full stack traces, I will not be able to make the appropriate patches to
>> fix the bug.
>>
>> There is no money on the table, and I have stopped actively developing
>> MaraDNS every since becoming a single parent with a full-time job. Welcome
>> to the world of open source economics: Since I’m not getting paid for my
>> time writing open-source software, I have very little time to devote to
>> MaraDNS.
>>
>> I will open up a GitHub bug so that users know I am aware of the bug. I
>> do not have a time frame for fixing the issue at this time. Hopefully by
>> the end of the year.
>>
>> -- Sam
>>
>> On Sat, Nov 12, 2016 at 10:18 AM, Luciano Bello <luci...@debian.org>
>> wrote:
>>
>>> Source: maradns
>>> Severity: grave
>>> Version: 2.0.13-1.2
>>> Tags: security upstream
>>>
>>> Hi,
>>>
>>> The following vulnerability was published for MaraDNS:
>>> http://seclists.org/oss-sec/2016/q4/411
>>>
>>> No CVE is was assigned yet, but the request was made in that thread.
>>> If you fix the vulnerability please also make sure to include the
>>> CVE (Common Vulnerabilities & Exposures) id in your changelog entry, if
>>> it is
>>> assigned soon.
>>>
>>> Please adjust the affected versions in the BTS as needed.
>>>
>>> Regards,luciano
>>>
>>>
>>
>

Bug#844121: Remote crash in MaraDNS 2.0.13

[Sam Trenholme]

Github bug: https://github.com/samboy/MaraDNS/issues/33

Please go here to get the latest updates from upstream about this issue.

On Sat, Dec 3, 2016 at 5:52 AM, Sam Trenholme <mara...@gmail.com> wrote:

> Hello there,
>
> I have just become aware of this bug. Right now, I can reproduce the crash
> in Cygwin 64-bit, but am unable to reproduce the crash in my 32-bit CentOS6
> development environment where I would actually be able to get a full stack
> trace (which was not provided in the original bug report). Until I can get
> a setup to reproduce the crashes in a manner which lets me have full stack
> traces, I will not be able to make the appropriate patches to fix the bug.
>
> There is no money on the table, and I have stopped actively developing
> MaraDNS every since becoming a single parent with a full-time job. Welcome
> to the world of open source economics: Since I’m not getting paid for my
> time writing open-source software, I have very little time to devote to
> MaraDNS.
>
> I will open up a GitHub bug so that users know I am aware of the bug. I do
> not have a time frame for fixing the issue at this time. Hopefully by the
> end of the year.
>
> -- Sam
>
> On Sat, Nov 12, 2016 at 10:18 AM, Luciano Bello <luci...@debian.org>
> wrote:
>
>> Source: maradns
>> Severity: grave
>> Version: 2.0.13-1.2
>> Tags: security upstream
>>
>> Hi,
>>
>> The following vulnerability was published for MaraDNS:
>> http://seclists.org/oss-sec/2016/q4/411
>>
>> No CVE is was assigned yet, but the request was made in that thread.
>> If you fix the vulnerability please also make sure to include the
>> CVE (Common Vulnerabilities & Exposures) id in your changelog entry, if
>> it is
>> assigned soon.
>>
>> Please adjust the affected versions in the BTS as needed.
>>
>> Regards,luciano
>>
>>
>

Bug#844121: Remote crash in MaraDNS 2.0.13

[Sam Trenholme]

Hello there,

I have just become aware of this bug. Right now, I can reproduce the crash
in Cygwin 64-bit, but am unable to reproduce the crash in my 32-bit CentOS6
development environment where I would actually be able to get a full stack
trace (which was not provided in the original bug report). Until I can get
a setup to reproduce the crashes in a manner which lets me have full stack
traces, I will not be able to make the appropriate patches to fix the bug.

There is no money on the table, and I have stopped actively developing
MaraDNS every since becoming a single parent with a full-time job. Welcome
to the world of open source economics: Since I’m not getting paid for my
time writing open-source software, I have very little time to devote to
MaraDNS.

I will open up a GitHub bug so that users know I am aware of the bug. I do
not have a time frame for fixing the issue at this time. Hopefully by the
end of the year.

-- Sam

On Sat, Nov 12, 2016 at 10:18 AM, Luciano Bello  wrote:

> Source: maradns
> Severity: grave
> Version: 2.0.13-1.2
> Tags: security upstream
>
> Hi,
>
> The following vulnerability was published for MaraDNS:
> http://seclists.org/oss-sec/2016/q4/411
>
> No CVE is was assigned yet, but the request was made in that thread.
> If you fix the vulnerability please also make sure to include the
> CVE (Common Vulnerabilities & Exposures) id in your changelog entry, if it
> is
> assigned soon.
>
> Please adjust the affected versions in the BTS as needed.
>
> Regards,luciano
>
>

Bug#785536: maradns: unreproducible deadwood binary

[Sam Trenholme]

Upstream here: No, you can not remove this functionality without
affecting security. Deadwood uses a home grown unpredictable hash
compression scheme; the more that the numbers are unpredictable, the
better.

If making the build process consistent is needed, feel free to edit
the Makefile to not rebuild the hash compression multiply constant
(the Windows Makefile is a good starting point to see how to do this).

To make the hash compression function more secure, it's possible to
replace it by SipHash. I will not do this myself (MaraDNS/Deadwood was
declared feature complete before SipHash existed), but I do have a
SipHash implementation that someone making a third-party fork of
Deadwood:

http://samiam.org/blog/20131006.html

- Sam

On Sun, May 17, 2015 at 8:15 AM, Reiner Herrmann rei...@reiner-h.de wrote:
 Source: maradns
 Version: 2.0.09-4
 Severity: wishlist
 User: reproducible-bui...@lists.alioth.debian.org
 Usertags: randomness
 X-Debbugs-CC: reproducible-bui...@lists.alioth.debian.org

 Hi!

 the deadwood binary can currently also not be built reproducibly.
 During building a new header DwRandPrime.h is generated with
 the tool RandomPrime, which is used in the deadwood source.

 Is there any reason why the MUL_CONSTANT has to differ on each build?
 Or could this also be made reproducible without affecting security?

 Regards,
  Reiner




-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#740049: Fwd: Bug#740049: maradns: [src:maradns] Fix in Makefile for deadwood (DwRandPrime.h generation)

[Sam Trenholme]

I forgot to give this to the bug database when replying.

-- Forwarded message --
From: Sam Trenholme mara...@gmail.com
Date: Wed, Feb 26, 2014 at 10:09 AM
Subject: Re: Bug#740049: maradns: [src:maradns] Fix in Makefile for
deadwood (DwRandPrime.h generation)
To: Tobias Frost t...@coldtobi.de


 - It always changes DwRandPrime.h and therefore changes the upstream
 source outside of the debian directory, and deb-source barks.

I would handle this problem in one of two ways:

* I would change the Makefile to have make clean not nuke DwRandPrime.h

* The Git version of MaraDNS/Deadwood has a similar problem, since I
can't include DwRandPrime.h in the Git tree (otherwise, it will change
every time I do a git commit -a -m '{description of change}'.  The
way I solved it there was to have the Windows Makefile in the Git tree
just use a static random number for the hash compress core:

https://github.com/samboy/MaraDNS/blob/master/deadwood-github/src/Makefile.mingw342

- Sam


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#740049: maradns: [src:maradns] Fix in Makefile for deadwood (DwRandPrime.h generation)

[Sam Trenholme]

I think that's a great patch; I have added it here:

http://maradns.samiam.org/download/patches/3rd_party/RandPrime.patch

And, for the record, my current policy is to not integrate third party
patches unless they fix security or other critical bugs:

http://samiam.org/blog/20120723.html

While I do appreciate third-party contributions to MaraDNS, I am the
one who takes responsibility for any bugs a patch I accept introduces.
I do not at present devote enough time to MaraDNS to be fixing bugs
introduced by patches.

As an update: MaraDNS now is in GitHub:  https://github.com/samboy/MaraDNS

- Sam

On Wed, Feb 26, 2014 at 1:37 PM, Tobias Frost t...@coldtobi.de wrote:
 Hallo Sam,

 Well, I do not really like auto-generated stuff in a repository /
 upstream source tarball ;-) ..
 Also somehow a fixed random number somehow feels against the spirit of
 randomness;-)

 So, may I propose #3?
 Enhancing RandPrime.c to fall-back to stdlib's random() if there is
 no /dev/urandom; I think this PRNG is better than a static random
 number. (See attached patch)


 --
 Tobias

 PS: you did not CC the Debian bug report; feel free to forward my
 message to it if this was not intended..


 Am Mittwoch, den 26.02.2014, 10:09 -0800 schrieb Sam Trenholme:
  - It always changes DwRandPrime.h and therefore changes the upstream
  source outside of the debian directory, and deb-source barks.

 I would handle this problem in one of two ways:

 * I would change the Makefile to have make clean not nuke DwRandPrime.h

 * The Git version of MaraDNS/Deadwood has a similar problem, since I
 can't include DwRandPrime.h in the Git tree (otherwise, it will change
 every time I do a git commit -a -m '{description of change}'.  The
 way I solved it there was to have the Windows Makefile in the Git tree
 just use a static random number for the hash compress core:

 https://github.com/samboy/MaraDNS/blob/master/deadwood-github/src/Makefile.mingw342

 - Sam



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#740049: maradns: [src:maradns] Fix in Makefile for deadwood (DwRandPrime.h generation)

[Sam Trenholme]

Upstream here:

Keep in mind that 'if [ -e /dev/urandom ] ; then ./RandomPrime 
DwRandPrime.h ; fi' is a rule in the middle of a Makefile and only
runs when DwRandPrime.h is not there.  The reason to have a fallback
DwRandPrime.h is so operating systems without /dev/urandom (yes, there
is a Windows port of this critter) can still have this file and
compile Deadwood.

The reason this is dynamically generated is to keep the hash function
random (the code has been there since 2007, over four years before
hash bucket collision attacks were common knowledge); in 2010, I made
the hash function random at runtime also (so people using precompiled
binaries are not vulnerable to hash bucket collision attacks).

- Sam

On Mon, Feb 24, 2014 at 11:08 PM, coldtobi t...@coldtobi.de wrote:
 Source: maradns
 Severity: minor
 Tags: patch

 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA256

 Hi Dariusz,

 when reviewing the package I found that a rule in the Makefile for deadwood is
 wrong and not generating DwRandPrime.h if not present.

 As this issue was introduced by a patch already in your package, I attach the
 *complete* patch for your convenience.  This is the diff on the patch:

 - --- a/debian/patches/deadwood_makefile.patch
 +++ b/debian/patches/deadwood_makefile.patch
 @@ -2,7 +2,7 @@ Author: Nicholas Bamber nicho...@periapt.co.uk
  Subject: deadwood source code corrupted during build
   Also we don't like binaries with a capital in the name.
  Forwarded: not-needed
 - -Last-Update: 2012-02-12
 +Last-Update: 2014-02-25
  --- a/deadwood-3.2.05/src/Makefile
  +++ b/deadwood-3.2.05/src/Makefile
  @@ -20,7 +20,7 @@
 @@ -34,7 +34,7 @@ Last-Update: 2012-02-12

   DwRandPrime.h: RandomPrime
  -  if [ -e /dev/urandom ] ; then ./RandomPrime  DwRandPrime.h ; fi
 - -+  if [ -e /dev/urandom -a -f DwRandPrime.h ] ; then mv -f 
 DwRandPrime.h DwRandPrime.h.bak ; ./RandomPrime  DwRandPrime.h ; fi
 ++  if [ -e /dev/urandom -a -f DwRandPrime.h ] ; then mv -f DwRandPrime.h 
 DwRandPrime.h.bak ; fi ; ./RandomPrime  DwRandPrime.h

 note that the only change is to move the fi to the left to unconditionally
 run ./RandomPrime, and not only if if has been there before.

 (With that patch applied, the current hack in d/rules (copying the backup
 d/DwRandPrime.h over the generated file in the clean target) can be replaced 
 by
 just deleting the file in d/clean. d/rules would just be more cleaner this 
 way)

 Thanks!

 - --
 Tobias Frost

 - -- System Information:
 Debian Release: jessie/sid
   APT prefers unstable
   APT policy: (500, 'unstable'), (500, 'testing')
 Architecture: amd64 (x86_64)
 Foreign Architectures: i386

 Kernel: Linux 3.12-1-amd64 (SMP w/4 CPU cores)
 Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
 Shell: /bin/sh linked to /bin/dash

 -BEGIN PGP SIGNATURE-
 Version: GnuPG v1

 iQIcBAEBCAAGBQJTDEFUAAoJEJFk+h0XvV02RCQP/2Y6fnYuOmhHaF7JQ2GN2SDW
 tuaDoEs/znztZhXoQdhBf5j+PViRbNBjo3buYILRsWnUafNSbfmPxMS1ioKPR/UX
 yslb5IUY7GTazvZc+JlNNXNuWqY1fzfla0dFI7zYScZKfz0cOY7GOAwMd+i2dr7o
 Jaqffg850tnGBz0g2BmLdebcPk59UUunq8rs+vGqzrJRQj432gpGeF6g6p98pH6h
 ouukZ0h6QLX7PKSFagKhSqRvA247qswOxiuCwjDab6f6zb53fvDe7hyg3erFySp4
 t51U9Skj8I5L0KVenZGtlTptEteK56G85MmeIttSlbfCwHXq1Z5tbm/CvrOJ2IOL
 CDtl+sTQ7KElOL2FnZ36CwE05uyxSebNAdR1jFHOYoboIBWrkwR+opnhv4DGaZcR
 Aw7f4LfJbSmZpCeaKNJLJ98mH7Zy6pT0l1sauGqMQ1eLIx3ALBJFzhpyAjdBuO63
 xNlCeXTwFJlwNNM1zxOoPxK/Fcep3MTPi9Cy8zMf0lojZXBw456cy53w5HZrELWy
 PP/yO6oXnDY79HkUNJ/IuwZzMSzMfBODLBsTkOpiab2GRk+NJ7AnqZBq//gpaTB7
 eP6p4yNKnaRE1/Eu40O654qp0gdw8Rdm5TriAGvpJKJCh8X47zHW2sG3v6E0pR2x
 1ffMu6Y/5qpKqgniIJ7s
 =/R1/
 -END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#665012: CVE-2012-1570: maradns deleted domain record cache persistance flaw

[Sam Trenholme]

Upstream here.  It's a six-line patch:

http://maradns.org/download/patches/security/maradns-1.4.11-ghostdomain.patch

This should not be too difficult to apply.

Also, the security report is somewhat inaccurate.  Both MaraDNS and
Deadwood were never vulnerable to the Ghost Domain bug as described
in the original report...something said report points out. However,
the programs were vulnerable to caching records with a long
TTL...easily fixed by capping TTLs to only last one day.

Finally, MaraDNS 1.4 will no longer be supported by me on June 21,
2015.  Please be sure to update all MaraDNS packages to 2.0 before
then.

- Sam

--- maradns-1.4.11/server/recursive.c   2012-01-13 13:39:01.0 -0600
+++ maradns-1.4.12/server/recursive.c   2012-03-17 09:52:27.0 -0600
@@ -1370,6 +1370,10 @@
 ttl = js_readuint32(server_reply,offset);
 if(ttl == JS_ERROR)
 return JS_ERROR;
+if(ttl  20)
+ttl = 20;
+if(ttl  86400) /* One day; Ghost domain fix */
+ttl = 86400;
 offset += 4;
 /* Get the rdlength of the SOA record */
 rdlength = js_readuint16(server_reply,offset);
@@ -2019,8 +2023,8 @@
problems that Franky reported */
 if(ttl  20)
 ttl = 20;
-if(ttl  63072000) /* Two years */
-ttl = 63072000;
+if(ttl  86400) /* One day; Ghost domain fix */
+ttl = 86400;
 /* If this is a CNAME answer then we don't store it for over
  * 15 minutes */
 if(ttl  900  cname_original_record != 0)

On Thu, Jan 17, 2013 at 3:42 AM, Jonathan Wiltshire j...@debian.org wrote:
 Package: maradns

 Dear maintainer,

 Recently you fixed one or more security problems and as a result you closed
 this bug. These problems were not serious enough for a Debian Security
 Advisory, so they are now on my radar for fixing in the following suites
 through point releases:

 squeeze (6.0.7) - use target stable

 Please prepare a minimal-changes upload targetting each of these suites,
 and submit a debdiff to the Release Team [0] for consideration. They will
 offer additional guidance or instruct you to upload your package.

 I will happily assist you at any stage if the patch is straightforward and
 you need help. Please keep me in CC at all times so I can
 track [1] the progress of this request.

 For details of this process and the rationale, please see the original
 announcement [2] and my blog post [3].

 0: debian-rele...@lists.debian.org
 1: http://prsc.debian.net/tracker/665012/
 2: 201101232332.11736.th...@debian.org
 3: http://deb.li/prsc

 Thanks,

 with his security hat on:
 --
 Jonathan Wiltshire  j...@debian.org
 Debian Developer http://people.debian.org/~jmw

 4096R: 0xD3524C51 / 0A55 B7C5 1223 3942 86EC  74C3 5394 479D D352 4C51



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#665012: sigh

[Sam Trenholme]

Join the club; I had to update all maintained versions of MaraDNS.
Indeed, this Ghost Domain bug has hit *all* major DNS servers:

http://samiam.org/blog/20120314.html

- Sam

On Fri, Mar 23, 2012 at 1:44 PM, Nicholas Bamber nicho...@periapt.co.uk wrote:
 Okay. Another release coming up.






-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#665012: CVE-2012-1570: maradns deleted domain record cache persistance flaw

[Sam Trenholme]

Upstream here:

Here are the affected versions of MaraDNS:

All MaraDNS 0 releases (Do NOT use; not maintained)
All MaraDNS 1.0 releases (Do NOT use; not maintained)
All MaraDNS 1.1 releases (Do NOT use; not maintained)
All MaraDNS 1.2 releases (Do NOT use; not maintained)
All MaraDNS 1.3 releases besides 1.3.07 (Do NOT use; not maintained)
All MaraDNS 1.3.07 releases before MaraDNS 1.3.07.15
All MaraDNS 1.4 releases before MaraDNS 1.4.12
All MaraDNS 2 releases before MaraDNS 2.0.06
All Deadwood 3 (subpackage of MaraDNS) releases before Deadwood 3.2.02
All Deadwood 2 releases besides 2.3 (Do NOT use; not maintained)
All Deadwood 2.3 releases before Deadwood 2.3.08

MaraDNS 1.3.07.15, 1.4.12, 2.0.06, as well as Deadwood 3.2.02 and
2.3.08 have been released to address this security bug.  It is
important that all MaraDNS users update to one of these versions.

Also: MaraDNS 1.3.07 will no longer be supported on December 21, 2012.
 Please upgrade to MaraDNS 1.4 or 2.0 at your soonest convenience if
feasible.  Here is an update guide:

http://maradns.org/tutorial/update.html

Distributions and users who wish to continue, against my wishes,
supporting an outdated version of MaraDNS 1 may (or may not) be able
to update MaraDNS 1 by using this patch:

http://maradns.org/download/patches/security/maradns-1.4.11-ghostdomain.patch

- Sam

On Thu, Mar 22, 2012 at 6:28 AM, Giuseppe Iuculano iucul...@debian.org wrote:
 Package: maradns
 Severity: serious
 Tags: security

 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1

 It was reported that MaraDNS suffers from a flaw where it is susceptible to
 spoofing attacks.  Due to an error in the cache update policy, which
 does not properly handle revoked domain names, a remote attacker could keep a
 domain name resolvable after it has been deleted from the registration.

 This flaw is fixed in versions 1.3.0.7.15 and 1.4.12, and is reported to
 affect all prior versions.

 References:

 http://www.maradns.org/changelog.html
 https://secunia.com/advisories/48492/
 https://bugzilla.redhat.com/show_bug.cgi?id=804770


 -BEGIN PGP SIGNATURE-
 Version: GnuPG v1.4.12 (GNU/Linux)

 iEYEARECAAYFAk9q/sIACgkQNxpp46476arqDQCfSFeWlawN7py9L5lKIE+xR1ix
 ATIAn0DxeHe7ugtuET2C9uHbJcAkIwkz
 =Pu/Y
 -END PGP SIGNATURE-






--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#653838: Inadequate source of entropy in recursive queries: maradns

[Sam Trenholme]

To add even more confusion:

I did a final tweak to the hash compression function yesterday.

TL;DR summary: Use MaraDNS 1.3.07.14, 1.4.10, any 2.0 release, or
apply this patch to an older release of MaraDNS:

http://maradns.org/download/patches/maradns-1.3-better_hash.patch

Long summary:

I made one release, realized that had problems, made another release
the next day, realized *that* had problems, and made a (hopefully
final) third update yesterday:

http://samiam.org/blog/20111229.html
http://samiam.org/blog/20111230.html
http://samiam.org/blog/20120113.html

- Sam

2012/1/14 Julien Cristau jcris...@debian.org:
 On Thu, Jan 12, 2012 at 22:55:10 +, Nicholas Bamber wrote:

 Julien,
       Comments below. What is the next step?

 On http://security-tracker.debian.org/tracker/source-package/maradns I
 see three issues: CVE-2011-5055, CVE-2011-5056 and CVE-2012-0024.  Which
 one is this fixing, and what's the status of the 2011-505* ones in
 unstable?  They're listed as unfixed in the tracker.

 Cheers,
 Julien



--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#653838: Inadequate source of entropy in recursive queries: maradns

[Sam Trenholme]

It's really old code and I did a much better job of it the second time
around.  Also: I'm not 100% satisfied with this hash compression
function, and will update it one last time for the MaraDNS 1 branch.

- Sam

2012/1/12 Julien Cristau jcris...@debian.org:
 On Sun, Jan  1, 2012 at 17:52:21 +, Nicholas Bamber wrote:

 Julien,
       The attached file is a debdiff for 1.4.03-1.1 - 1.4.03-1.2. I have not
 run an FTBS test on it but I wanted to know if I was on the right lines.

 Looks basically ok, there's a couple oddities but I guess they're that
 way upstream?

 diff -u maradns-1.4.03/debian/copyright maradns-1.4.03/debian/copyright
 --- maradns-1.4.03/debian/copyright
 +++ maradns-1.4.03/debian/copyright
 @@ -4,7 +4,7 @@

  Files: *
  Copyright:
 - (C) 2002-2010 Sam Trenholme mara...@gmail.com
 + (C) 2002-2011 Sam Trenholme mara...@gmail.com
  License: BSD license

  Files: debian/*
 diff -u maradns-1.4.03/debian/changelog maradns-1.4.03/debian/changelog
 --- maradns-1.4.03/debian/changelog
 +++ maradns-1.4.03/debian/changelog
 @@ -1,3 +1,9 @@
 +maradns (1.4.03-1.2) stable; urgency=low
 +
 +  * Applied patch to ensure adequate entropy (Closes: #653838)
 +
 + -- Nicholas Bamber nicho...@periapt.co.uk  Sun, 01 Jan 2012 16:29:53 
 +
 +
  maradns (1.4.03-1.1) unstable; urgency=high

    * Non-maintainer upload by the Security Team
 only in patch2:
 unchanged:
 --- maradns-1.4.03.orig/server/MaraDNS.c
 +++ maradns-1.4.03/server/MaraDNS.c
 @@ -3933,6 +3933,24 @@
      int recurse_number_ports = 4096;
  #endif

 +    /* First order of business: Initialize the hash */
 +    if(mhash_set_add_constant(
 +#ifdef MINGW32
 +     secret.txt
 +#else
 +     /dev/urandom
 +#endif
 +             ) != 1) {
 +     printf(
 +#ifdef MINGW32
 +     Fatal error opening secret.txt
 +#else
 +     Fatal error opening /dev/urandom
 +#endif

 Shouldn't that go to stderr?

 +                     );
 +                     return 32;
 +     }
 +
      memset(client,0,sizeof(client)); /* Initialize ya variables */
      clin = (struct sockaddr_in *)client;
  #ifdef AUTHONLY
 only in patch2:
 unchanged:
 --- maradns-1.4.03.orig/libs/MaraHash.c
 +++ maradns-1.4.03/libs/MaraHash.c
 @@ -1,4 +1,4 @@
 -/* Copyright (c) 2006 Sam Trenholme
 +/* Copyright (c) 2006,2011 Sam Trenholme
   *
   * TERMS
   *
 @@ -32,6 +32,7 @@
  #include JsStr.h
  #endif
  #include MaraHash.h
 +#include stdio.h

  /* Masks to limit the size of the hash */
  /* These are powers of two, minus one */
 @@ -41,6 +42,8 @@
                            16777215, 33554431, 67108863, 134217727,
                            268435455, 536870911, 1073741823 };

 +mhash_offset mhash_secret_add_constant = 7;
 +
  /* Create a new, blank mhash object
     input: none
     output: pointer to the object in quesiton on success, NULL (0)
 @@ -100,6 +103,7 @@
      /* Simple enough hash */
      while(point  max) {
          ret += (mhash_offset)(*point  shift);
 +     ret += mhash_secret_add_constant;

 odd indent.

          shift += 7;
          shift %= hash_bits;
          point++;
 @@ -684,3 +688,23 @@
      return tuple-tuple_list[element];
      }

 +/* Read four bytes from a filename and use that as a secret add constant */
 +int mhash_set_add_constant(char *filename) {
 +     FILE *read = 0;

 and odd choice of variable name.

 +
 +     read = fopen(filename,rb);
 +     if(read == NULL) {
 +             return -1;
 +     }
 +
 +     mhash_secret_add_constant ^= getc(read);
 +     mhash_secret_add_constant = 8;
 +     mhash_secret_add_constant ^= getc(read);
 +     mhash_secret_add_constant = 8;
 +     mhash_secret_add_constant ^= getc(read);
 +     mhash_secret_add_constant = 7;
 +     mhash_secret_add_constant ^= getc(read);
 +     fclose(read);
 +     return 1;
 +}
 +
 only in patch2:
 unchanged:
 --- maradns-1.4.03.orig/libs/functions_MaraHash.h
 +++ maradns-1.4.03/libs/functions_MaraHash.h
 @@ -39,3 +39,5 @@
  */
  void *mhash_undef(mhash *hash, js_string *key);

 +/* Read four bytes from a filename and use that as a secret add constant */
 +int mhash_set_add_constant(char *filename);

 Cheers,
 Julien



--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#653838: Inadequate source of entropy in recursive queries: maradns

[Sam Trenholme]

 Shouldn't that go to stderr?

 Actually the stdout gets piped into a related logger process.

I tried to have the logger thing to have two pipes open, one for
stdout, another for stderr, and give things received on stderr a
different log priority, but it didn't work.  There is discussion on
the mailing list from 2002 or 2003 where I said this code isn't
working and D Richard Felker III told me you can't pipe both stdout
and stderr.

 odd indent.
 I hate the indenting in the souce code generally.

I did a better job of indenting it the second time around (Deadwood).

 and odd choice of variable name.
 You're worried about a clash between the variable name and unction
 sysmbols? I guess this could be changed and sent upstream.

If it makes people happier, I can change the variable name.  However,
that patch will also make a one-line change to the hash compression
thingy.



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#635254: maradns: Normally functionality forced to go via TCP fails

[Sam Trenholme]

Upstream here:  MaraDNS' dns-over-tcp support is done via a separate
daemon.  Details on how to set up this daemon are here:

http://maradns.org/tutorial/dnstcp.html

I current am not receiving sufficient sponsorship to integrate TCP in
to MaraDNS proper.   Note that Deadwood has both UDP and TCP support
in the same daemon.

- Sam



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#459339: ideas for fixing this

[Sam Trenholme]

 Unfortunately, what Duende doesn't do is wait around a few seconds before
 daemonizing to make sure that MaraDNS does not have some syntax error in
 the mararc file or something else that makes MaraDNS exit right away.
 So, any script that checks to see if MaraDNS is running is going to have
 to use start-stop-daemon and see if the pid in the appropriate pidfile
 is in the process list with the name duende.

Thank you for the feature request.  I currently have no plans to
implement new features in MaraDNS without being fairly compensated for
my time and work.

- Sam



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#459339: ideas for fixing this

[Sam Trenholme]

Upstream here: Is the Debian package using the Duende tool included
with MaraDNS?

http://www.maradns.org/tutorial/man.duende.html

- Sam

 I believe the problem here is that maradns does not detach itself like a
 proper daemon should.



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#607739: Upstream here: Fixed

[Sam Trenholme]

This is upstream letting people know this bug has been fixed upstream.

The source tarball with this issue fixed can be downloaded here:

http://www.maradns.org/download/2.0/snap/

Just the patch to fix this issue is here:

http://www.maradns.org/download/patches/normal/maradns-2.0.02-debian_bug_607739_fix.patch

Chris: Please download the tarball -or- apply the patch and confirm
that this issue is resolved.

Nicholas: This bug has been fixed upstream.  Please change the status
of the bug.

Everyone: Thank you for your interest in MaraDNS.

I plan on releasing a version of MaraDNS 2 with this issue resolved on
July 8.  I have no plans to backport this patch to MaraDNS 1.4.

- Sam



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#610834: MaraDNS 1.4.06 and 1.3.07.11 released

[Sam Trenholme]

In 2002, when I rewrote the compression code for MaraDNS for the first
time, I made a mistake in allocating an array of integers, allocating
it in bytes instead of sizeof(int) units.  The resulted in a buffer
being too small, allowing it to be overwritten.

The impact of this programming error is that MaraDNS can be crashed by
sending MaraDNS a single packet of death.  Since the data placed in
the overwritten array can not be remotely controlled (it is a list of
increasing integers), there is no way to increase privileges
exploiting this bug.

The attached patch resolves this issue by allocating in sizeof(int)
units instead of byte-sized units for an integer array.  In addition,
it uses a smaller array because a DNS name can only have, at most, 128
labels.

I would like to thank Mr. Witold Baryluk for pointing out this issue,
taking the time to backtrace the bug, and for bringing it to my
attention by posting to the MaraDNS mailing list.  However, I need to
let him know that making this public by filing a public Debian bug
without first trying to contact me is not the appropriate way to
handle a security problem with MaraDNS.  The appropriate way to do so
is via private email.  My email address is here:

http://samiam.org/mailme.php

(mara...@gmail.com was an account created so I could make entries in
an older MaraDNS blog, and is not presently actively looked at)

As it turns out, I only occasionally look at the Debian bug database
and people with issues with MaraDNS would be better off joining the
MaraDNS mailing list instead of filing a Debian bug (unless the issue
is Debian-specific).

In response to this bug, I have released MaraDNS 1.4.06 and 1.3.07.11.
 These releases are available here:

http://maradns.org/download.html

Since sourceforge.net has recently suffered a security breach, their
file uploading feature is currently undergoing maintenance and new
files currently can not be uploaded there.

I have not made a new release of MaraDNS 2.0 yet.  Yarin has
contributed a number of patches, and I would like to integrate his
patches before making a new MaraDNS 2.0 release; MaraDNS 2.0 users can
use the supplied patch.

As an aside, I have become a better programmer since making this
mistake back in 2002.  Deadwood, which is a complete rewrite of
MaraDNS' recursive code, does not have this issue in its
compression/decompression code.  Instead of using different data types
in structures, Deadwood, by and large, uses special overflow-resistant
strings to store most data.

Also, I would like to take the time to make a public service
announcement for djbdns users: DjbDNS 1.05 does have known security
issues, and needs to be patched.  More details are here:

http://samiam.org/blog/20110103.html

(I am making this announcement because I have seen people, as recently
as last year, claiming djbdns-1.05 is perfectly secure on public
forums)

- Sam

--- maradns-1.4.05/dns/Compress.c   2010-07-31 01:17:08.0 -0600
+++ maradns-1.4.06/dns/Compress.c   2011-01-28 18:28:46.0 -0700
@@ -22,7 +22,7 @@
 #include functions_dns.h

 /* Maximum allowed number of dlabel points */
-#define MAX_DLABEL_POINTS 512
+#define MAX_DLABEL_POINTS 160

 /* Maximum allowed length of compressed string; this is 4096 for TCP
  * packets */
@@ -87,7 +87,8 @@
 js_dealloc(new);
 return 0;
 }
-if((new-dlabel_points = js_alloc(MAX_DLABEL_POINTS + 3,1)) == 0) {
+if((new-dlabel_points = js_alloc(MAX_DLABEL_POINTS + 3,sizeof(int)))
+   == 0) {
 js_destroy(new-compressed);
 js_dealloc(new);
 return 0;


maradns-1.4.05-CVE-2011-0520.patch
Description: Binary data

Bug#507591: maradns: Segmentation fault when using a config file with syntax error

[Sam Trenholme]

Upstream here.  This issue was never present in MaraDNS 1.2, and has
been fixed in MaraDNS 1.3.07.10 and MaraDNS 1.4.03.  If Debian
versions of MaraDNS still have this bug, they need to incorporate my
fix, or, better yet, upgrade to 1.3.07.10 or 1.4.03.

- Sam

Note: I do not answer MaraDNS (including Deadwood) support requests
sent by private email without being compensated for my time. A MaraDNS
support request is any and all discussion you may wish to have about
MaraDNS in private email; if you want to email me to talk about
MaraDNS then, yes, that is a support request. I will discuss rates if
you want this kind of support. Thank you for your understanding.

MaraDNS security vulnerability reports, however, will be dealt with
without charge and kept confidential. If you don't know what Bugtraq
is, then, no, your email is not a security report. It is not a
security report unless you've done due diligence to determine how the
security bug you think you found can reasonably be exploited.



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#525188: Upstream here on recursive AAAA records.

[Sam Trenholme]

Upstream here.  Sorry for the delay, but I wanted to wait until I
could give people a real solution to this issue.

Just this last day, I have released Deadwood 2.9.01, which is the
daemon that will become MaraDNS 2.0's recursive resolver.  This daemon
fixes a number of long-standing issues MaraDNS 1.0's recursive
resolver has, including CNAMEs pointing to  records.

Fully recursive Deadwood is not ready to be marked stable, but I
have fixed all of the obvious bugs and it's a matter of getting the
code out there and getting it hammered on so I can hunt down and fix
bugs people find.

This particular issue is one that I will not fix in MaraDNS 1.x (IPv6
does not have wide adoption yet, and MaraDNS 2.0 should be out there
by the time it does), but it has already been fixed for MaraDNS 2.0.

- Sam

Note: I do not answer MaraDNS (including Deadwood) support requests
sent by private email without being compensated for my time. A MaraDNS
support request is any and all discussion you may wish to have about
MaraDNS in private email; if you want to email me to talk about
MaraDNS then, yes, that is a support request. I will discuss rates if
you want this kind of support. Thank you for your understanding.

MaraDNS security vulnerability reports, however, will be dealt with
without charge and kept confidential. If you don't know what Bugtraq
is, then, no, your email is not a security report. It is not a
security report unless you've done due diligence to determine how the
security bug you think you found can reasonably be exploited.



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#486497: seemingly arbitrary restriction not to bind to 0.0.0.0

[Sam Trenholme]

Upstream here.  It's a really bad idea to bind MaraDNS to 0.0.0.0, but
if you insist on doing it, it can be done if csv2_synthip_list is set.

- Sam

Note: I do not answer MaraDNS (including Deadwood) support requests
sent by private email without being compensated for my time. A MaraDNS
support request is any and all discussion you may wish to have about
MaraDNS in private email; if you want to email me to talk about
MaraDNS then, yes, that is a support request. I will discuss rates if
you want this kind of support. Thank you for your understanding.

MaraDNS security vulnerability reports, however, will be dealt with
without charge and kept confidential. If you don't know what Bugtraq
is, then, no, your email is not a security report. It is not a
security report unless you've done due diligence to determine how the
security bug you think you found can reasonably be exploited.



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#484466: provide a reload method

[Sam Trenholme]

Upstream here.  If MaraDNS is run using the duende daemonizer, sending
MaraDNS a HUP signal will stop and restart MaraDNS, reloading all
configuration and zone files.

- Sam

Note: I do not answer MaraDNS (including Deadwood) support requests
sent by private email without being compensated for my time. A MaraDNS
support request is any and all discussion you may wish to have about
MaraDNS in private email; if you want to email me to talk about
MaraDNS then, yes, that is a support request. I will discuss rates if
you want this kind of support. Thank you for your understanding.

MaraDNS security vulnerability reports, however, will be dealt with
without charge and kept confidential. If you don't know what Bugtraq
is, then, no, your email is not a security report. It is not a
security report unless you've done due diligence to determine how the
security bug you think you found can reasonably be exploited.



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#573970: maradns: please provide an include statement for mararc

[Sam Trenholme]

Upstream here.  There are no plans to add this to the authoritative
MaraDNS code, but the up-and-coming MaraDNS 2.0 release will use a
separate daemon for recursion called Deadwood (I just released the
first beta-test version of this daemon this last day), which does
support includes via Python-compatible execfile(filename) syntax.

- Sam

Note: I do not answer MaraDNS (including Deadwood) support requests
sent by private email without being compensated for my time. A MaraDNS
support request is any and all discussion you may wish to have about
MaraDNS in private email; if you want to email me to talk about
MaraDNS then, yes, that is a support request. I will discuss rates if
you want this kind of support. Thank you for your understanding.

MaraDNS security vulnerability reports, however, will be dealt with
without charge and kept confidential. If you don't know what Bugtraq
is, then, no, your email is not a security report. It is not a
security report unless you've done due diligence to determine how the
security bug you think you found can reasonably be exploited.



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#477787: fails to bind to ipv6 addresses

[Sam Trenholme]

Upstream here: MaraDNS 2.0 will have full IPv6 support.  I have just
made a beta-test release of the relevant code (MaraDNS 2.0's
up-and-coming recursor, Deadwood) and encourage people to test it and
report bugs on the MaraDNS mailing list.

- Sam

Note: I do not answer MaraDNS (including Deadwood) support requests
sent by private email without being compensated for my time. A MaraDNS
support request is any and all discussion you may wish to have about
MaraDNS in private email; if you want to email me to talk about
MaraDNS then, yes, that is a support request. I will discuss rates if
you want this kind of support. Thank you for your understanding.

MaraDNS security vulnerability reports, however, will be dealt with
without charge and kept confidential. If you don't know what Bugtraq
is, then, no, your email is not a security report. It is not a
security report unless you've done due diligence to determine how the
security bug you think you found can reasonably be exploited.



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#486497: seemingly arbitrary restriction not to bind to 0.0.0.0

[Sam Trenholme]

The reason why setting things up to allow binding to 0.0.0.0 is an
undocumented feature and why I strongly encourage people to not do it
is because I have had reports of occasional buggy behavior caused by
0.0.0.0 binding.

It's a case of a doing this voids the warranty; I'm not responsible
for any resulting buggy behavior caused by binding to 0.0.0.0.

- Sam

Note: I do not answer MaraDNS (including Deadwood) support requests
sent by private email without being compensated for my time. A MaraDNS
support request is any and all discussion you may wish to have about
MaraDNS in private email; if you want to email me to talk about
MaraDNS then, yes, that is a support request. I will discuss rates if
you want this kind of support. Thank you for your understanding.

MaraDNS security vulnerability reports, however, will be dealt with
without charge and kept confidential. If you don't know what Bugtraq
is, then, no, your email is not a security report. It is not a
security report unless you've done due diligence to determine how the
security bug you think you found can reasonably be exploited.



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#436214: no warning on failure to start

[Sam Trenholme]

Upstream here.  This looks to be a feature request.  I will try to explain
how MaraDNS is started, in order to help downstream look at this feature
request.

Basically, the original MaraDNS 1.0 did not daemonize, but depended on
non-POSIX Bash-isms like 'maradns ' in order to become a daemon.  
People in 1.0 asked me to make MaraDNS daemonizable, so I did that in 
the 1.1 unstable brach of MaraDNS over four years ago.

I did so by writing a small program about 200 lines long called 
'duende'.  Duende is responsible for making MaraDNS a daemon, and using 
syslog() to log MaraDNS' output.  Duende also handles the 'kill -HUP' 
old-school BSD hack by, when getting a HUP signal, restarting MaraDNS.  
Should MaraDNS get a HUP signal, it exits with an exit code of 8, which 
tells Duende to restart MaraDNS.  If Duende gets a TERM signal, it sends 
a term signal to MaraDNS and exits.  Should MaraDNS exit with a non-8 
exit code, Duende will also exit.

Unfortunatly, what Duende doesn't do is wait around a few seconds before 
daemonizing to make sure that MaraDNS does not have some syntax error in 
the mararc file or something else that makes MaraDNS exit right away.  
So, any script that checks to see if MaraDNS is running is going to have 
to use start-stop-daemon and see if the pid in the appropriate pidfile 
is in the process list with the name duende.

Again, doing this in a manner so scipts can more easily make sure 
everything is OK with MaraDNS is a feature request.  Right now, MaraDNS 
is in a testing cycle that should end with a stable release on December 
21, 2007.  No new features are going to be added to MaraDNS between now 
and then.

I can not guarantee that MaraDNS will get this feature.  There are a lot 
of feature requests on the table right now, and no one (so far) is 
willing to pay to have any of these features implemented.  This is the 
downside of open-source software: since no one is paying me to write 
this code, I have little motivation to implement features that don't 
directly benefit myself.

The tech industry was not very good to me after the 2001 dot-com 
implosion.  Even though I have a lot of talent, after getting my degree 
in computational linguistics, I ended up working as a cashier at 
Wal-Mart.  This was the result of a three-month job search in late 2005.  
I only got one interview during those three months.  This, even though I 
had five years of experience in the industry beforehand.  Basically, 
clueless HR departments didn't care if I had five years of programming 
experience; it had to be five years of, say, PHP experience, or they 
would throw my resume away.

MaraDNS development doesn't help me have a nice-looking resume; if 
MaraDNS was written in PHP, Java, or whatever the current 
buzzword-compliant language is, I may be able to get interviews.  But 
it's written in C.  The only C programming that would have gotten me 
interviews in 2005 was device driver development.  Or if MaraDNS was 
written in C++, that would have been buzzword-compliant enough in 2005 
to get me interviews.

I'm now an English teacher in Mexico, of all things.  

- Sam



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#438913: maradns: Remote DoS attack possible

[Sam Trenholme]

Upstream here.  After some effort, and help from Moritz Muehlenhoff and
Kai Hendry, the fix for the security issue in question was backported
to MaraDNS 1.2.12.04 a while ago.   There seems to be some Debian
policy somewhere that states that, once cristened stable, a given
version of a software package will only be updated if the updates are
security-critical.

The relevant bug is Debian bug #425753.  And, yes, as per that bug, I 
would prefer that Debian would update to 1.2.12.06 (or, better yet, 
1.2.12.07), but Debian policy is Debian policy.

- Sam


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#436209: resolvconf update script breaks maradns configuration

[Sam Trenholme]

Upstream here.  Just letting you guys know that I didn't write this script.
However, I think I will look at it.  If its license is MaraDNS-compatible, I
may even add it to MaraDNS proper.

Indeed, I would like to see Debian-specific stuff like this become part of 
the next 1.3 stable release of MaraDNS.

- Sam


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#425753: MaraDNS 1.2.12.04 security patches

[Sam Trenholme]

If I understnad Kai correctly, the only changes done in stable are
security updates.  The two patches patch important security concerns
that MaraDNS 1.2.12.04 has (remote denial of service).  Please, if it
is not feasable to update stable to 1.2.12.06, at least apply these
two patches to 1.2.12.04.

If these patches do not cleanly patch against 1.2.12.04, let me know.

- Sam (MaraDNS upstream)


maradns-1.3.02-ect.d-leakfix.patch
Description: Binary data


maradns-1.3.04-memleak.patch
Description: Binary data

Bug#425753: maradns - important security upgrade

[Sam Trenholme]

Package: maradns
Version: 1.2.12.05

Hello everyone, this is upstream for the package maradns.

There is an important security hole that has been patched in MaraDNS
1.2.12.06.  The impact of this security hole is: Remote denial of
service.  In more detail, the security problem allows a remote
attacker to cause MaraDNS to allocate an arbitrary large amount of
memory.

MaraDNS 1.2.12.06 resolves this issue.

Now, I'm a little frustrated with the Debian bureaucracy.  As it turns
out, the 1.2 branch is a STABLE branch.  I don't add new features to
this branch.  I only add bugfixes that are unlikely to cause problems.
Compared to MaraDNS 1.2.12.04, the only changes in 1.2.12.06 are as
follows:

* LOC records with a precision that is a multiple of 10 now work.

* Memory leak found by Rani Assaf plugged.

* Whether to give a NXDOMAIN or a not there reply with star records
fixed to be RFC1034 and RFC4074 compliant.

* Hosts in a csv2_default_zonefile now correctly return a not there
instead of a NXDOMAIN (unless there is no host of any RR type that
matches the desired name).

* João Antunes Predator tool found two memory leaks. Fixed.

These are really minor bugfixes.  The patches probably total less than
250 lines of code.  These fixes fix RFC violations that cause
real-world problems (well, except for the be anal fix that makes
host names with stars 100% RFC1034 section 4.3.3 compliant, but that's
disabled by default), or security issues (three, count them, three
remote memory leaks).   I see no reason whatsoever to stay with
1.2.12.04.

It's ultimately your decision whether to stay with maradns-1.2.12.04
or allow Debian's user to update to a bug fix release that adds no
features and only fixes bugs.  But, the idea that a software release
with more bugs, including security bugs, is somehow more stable just
because it has been around is rather silly.

Anyway, enough of my rant.  1.2.12.06 is available at the following places:

http://www.maradns.org/download.html
http://sourceforge.net/projects/maradns
http://hotaru.chaosring.org/~sam/maradns-1.2.12.06/

And I would like to see Debian update to this release.

Thank you for your time,

- Sam (MaraDNS upstream)

Bug#397064: I can not reproduce this

[Sam Trenholme]

When a maintainer for a MaraDNS port one day loses interest in keeping
MaraDNS up to date (as has happened with the FreeBSD port of MaraDNS)

TIme for me to put my foot in my mouth.  The FreeBSD maintainer has dnot 
lost any interest in MaraDNS.  I sent a gentle message to [EMAIL PROTECTED]
about the issue, and the port was updated to 1.2.12.04 very quickly.

I apologize for implying that the FreeBSD porter of MaraDNS was
unreliable; he was on the ball and the FreeBSD port is now up to
date.

- Sam


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#384943: start/stop zoneserver

[Sam Trenholme]

OK, guys, I have finally made Boris' zoneserver patch a part of MaraDNS
1.3.  This modifies zoneserver to kill all of its children when it gets a
TERM signal.

This patch is only available in the snapshot:

http://www.maradns.org/download/1.3/snap/200612/

I just made it part of the December 13th snapshot.

This patch won't become part of 1.2, for reasons I have already posted
Basically, 1.2 is now in a fix serious bugs only freeze and I'm slowly
starting to work on 1.3.

- Sam


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#384943: start/stop zoneserver

[Sam Trenholme]

This is just upstream here letting everyone know that 1.2.12.03 does not
change any of the code around the patched Boris has been giving us, so
those patches can be integrated with the new release just fine. 
1.2.12.03 is a bugfix-only release; the only additions are a HTML 
document advocating MaraDNS and an incomplete Python script to convert
BIND zone files in to MaraDNS-comparible CSV2 zone files.

- Sam


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#384943: start/stop zoneserver

[Sam Trenholme]

Upstream here, finally.  Sorry about the delay replying to this issue,
I've been juggling no less than three different jobs and have been spending
my free time this last week playing with Greg Strong's excellent ChessV
program (http://sourceforge.net/projects/chessv) to help research a
Chess variant that I've invented (Schoolbook Chess).

Anyway, enough of the excuses and let me look at this issue.  

All zoneserver processes are correctly killed when using the upstream
zoneserver process killer.  The script in question has this bit of
code:

ps -ef | awk '{print $2:$8}' | grep zoneserver | grep -v $$ | \
  cut -f1 -d: | xargs kill  /dev/null 21

English translation: Send a term signal to all processes running on 
the machine with the name zoneserver

This is followed by:

ps -e | awk '{print $1:$NF}' | grep zoneserver | grep -v $$ | \
  cut -f1 -d: | xargs kill -9  /dev/null 21

So my script doesn't have this issue.

Now, in terms of the patch for the zoneserver that has the zoneserver
also be able to kill its own children, I agree this is a good idea.
However, the patch is too big a change for the current stable branch,
1.2.12.  I don't know if getpgrp(), setpgrp(), and killpg() exist
on all systems MaraDNS' zoneserver is supposed to compile on (Mac OS X,
the *BSDs--though Adam Montage has given me an account I can do OpenBSD
testing on, Solaris, etc).  What I will do is make this a change for 
the 1.2.13 release of MaraDNS which will come out one of these days.

I appreciate Boris submitting this patch to MaraDNS.

Now, in terms of MaraDNS progress, I'm slowly but surely working on the
BIND to CSV2 converython script.  You can see my progress here:

http://www.maradns.org/download/1.2/snap/200609/

Anyway, thanks guys for your interest in MaraDNS.  This is, from where
I am sitting, WONTFIX for the 1.2.12 branch, but the patch will be 
applied in 1.2.13.

- Sam


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#352331: combined A/PTR records?

[Sam Trenholme]

This is upstream for MaraDNS here.

This feature (with the name FQDN4) has been added to the 1.2.07 branch
of MaraDNS.

To the powers that be: This bug can now be closed.

- Sam

Bug#373781: resolver fails if CNAME points to A record in non-authoritative domain

[Sam Trenholme]

For the record, I am upstream for MaraDNS.

I've just re-added the FAQ entry about this issue:

http://www.maradns.org/faq.html#cname

This issue can be easily enough worked around.

To the powers that be: This can be closed as WONTFIX if desired; it's a 
known MaraDNS issue.

- Sam