Oh and I should have been talking about CVE-2011-5056 anyway. But I do
think CVE-2011-5055 is resolved.
On 24/01/12 20:14, Nicholas Bamber wrote:
> Moritz,
> Actually it is acknowledged to be present in 2.0.04-*.
>
> On 24/01/12 19:05, Moritz Muehlenhoff wrote:
>> On Tue, Jan 24, 2012 at 03
Moritz,
Actually it is acknowledged to be present in 2.0.04-*.
On 24/01/12 19:05, Moritz Muehlenhoff wrote:
> On Tue, Jan 24, 2012 at 03:32:29PM +, Nicholas Bamber wrote:
>> Second attempt at preparing a fix for this issue.
>>
>> By the way CVE-2011-5055, as far as I can see, only appl
On Tue, Jan 24, 2012 at 03:32:29PM +, Nicholas Bamber wrote:
> Second attempt at preparing a fix for this issue.
>
> By the way CVE-2011-5055, as far as I can see, only applies to the
> experimental release. That will be fixed when upstream issue a new
> upstream 2.x release. Could the securit
Second attempt at preparing a fix for this issue.
By the way CVE-2011-5055, as far as I can see, only applies to the
experimental release. That will be fixed when upstream issue a new
upstream 2.x release. Could the security page be updated to reflect that.
On 18/01/12 13:24, Adam D. Barratt wro
On 15.01.2012 20:39, Nicholas Bamber wrote:
unstable/testing [CVE-2012-0024, CVE-2011-5055]: This was fixed in
1.4.09-1 but Sam has issued one further release, 1.4.10 with a last
tweak. For this version all the three CVE tickets are fundamentally
the
same issue.
stable [CVE-2012-0024, CVE-2011
I think I have got a handle on what is going on here:
http://samiam.org/blog/20111229.html
experimental [CVE-2011-5056]: This only affects the authoritative
server. In previous versions this would be the same issue as the other
CVS tickets because then the authoritative and recursive servers were
This is getting a bit tedious but we have a clarification:
http://woodlane.webconquest.com/pipermail/list/2012-January/001050.html
On 14/01/12 12:18, Julien Cristau wrote:
> On Thu, Jan 12, 2012 at 22:55:10 +, Nicholas Bamber wrote:
>
>> Julien,
>> Comments below. What is the next step?
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
I reckon there must be some confusion here. The description in
CVE-2011-5056 does not match the link to Sam's blog. SO I have no idea
what is going on there. In any case if the attack vector is crafting
authoritative DNS records, then the system would have to be compromised
in other ways to make th
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
Julien,
Comments below. What is the next step?
On 12/01/12 21:40, Julien Cristau wrote:
> 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 k
Julien,
Thanks. That schedule seems elatively comfortable.
On 31/12/11 15:00, Julien Cristau wrote:
> On Sat, Dec 31, 2011 at 14:30:04 +, Nicholas Bamber wrote:
>
>> As per the attached email, I wonder if you would be interested in point
>> releases for the old versions of maradns to
12 matches
Mail list logo