[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
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
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
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
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
.
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
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
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)
, 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
>&g
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.
s 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: http
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 repr
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).
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
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
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
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
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
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.
--
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
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
/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
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
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
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
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
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:
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
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
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
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
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
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
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
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
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.
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
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
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
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
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
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
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
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
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
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
46 matches
Mail list logo
