[distcc] [distcc-patches] Re: [PATCH] IPv6 ACLs

[Fergus Henderson]

I applied this patch.
Then I remember to run "make check", and it turns out that "make check"
fails with a compile error in code used for testing.
So I've sent a patch for the compile error.
I also made some stylistic improvements that I've sent as a separate patch.

However, the failure of "make check" also reminds me that it would be nice
to have some tests of the IPv6 address parsing and access control,
analogous to the AccessDenied_Case and ParseMask_Case tests in
test/testdistcc.py.  If you could make a patch for that, I'd really
appreciate it.

Cheers,
  Fergus.

On Wed, Jul 22, 2009 at 10:32 AM, Fergus Henderson <
fergus.henderson at gmail.com> wrote:

> Looks good to me.
>
> There are some minor style issues where improvements are possible, e.g.
> using *iptr++ = ... everywhere instead of mixing the increments of iptr in
> the for(); and using the same type with just the ipv6 field of the union
> #ifdef'd, rather than the whole type. But this I'd fine as is.
>
>
> On Jul 21, 2009, at 5:15 AM, Bob Ham <rah at bash.sh> wrote:
>
>  On Mon, 2009-07-20 at 22:23 -0400, Fergus Henderson wrote:
>>
>>  Oh, I see that the old code that this is replacing didn't check the
>>> return value of strdup() either.
>>>
>>
>> Indeed, both of the issues you raised were a continuation of the modus
>> operandi.  As you noted, the return value of strdup() was not checked.
>> Also, the following non-standard C was used in srvnet.c:
>>
>> -            const in_addr_t *a4;
>> ...
>> -                a4 = (const in_addr_t *) &a6->s6_addr[12];
>>
>>
>> Regardless, I've updated the patch to correct these issues.  I've also
>> made two more updates.  One is a fix to ensure the maximum bit mask size
>> is set according to the address family and not just whether RFC2553
>> support is enabled.
>>
>> The other, slightly more worrying update modifies the non-RFC2553 code
>> to use inet_aton() instead of inet_pton().  The inet_pton() function is
>> defined in RFC2553.  This is worrying because it means that people have
>> been compiling distcc without RFC2553 support enabled but still using a
>> function defined by that RFC.  The fact that this state has continued
>> without being noticed previously calls into question the value of
>> maintaining non-RFC2553 code at all.
>>
>>
>> --
>> Bob Ham <rah at bash.sh>
>>
>> --~--~---------~--~----~------------~-------~--~----~
>> You received this message because you are subscribed to the
>> "distcc-patches" list.
>> To post to this list, send email to <distcc-patches at googlegroups.com>.
>> To unsubscribe from this list, send email to <
>> distcc-patches-unsubscribe at googlegroups.com>.
>> For archives and more options, see <
>> http://groups.google.com/group/distcc-patches>.
>> -~----------~----~----~----~------~----~------~--~---
>>
>> <distcc-v6-acl-2.patch>
>>
>


-- 
Fergus Henderson <fergus.henderson at gmail.com>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.samba.org/pipermail/distcc/attachments/20090722/e7a8eb7c/attachment.html>