Re: [Sqlgrey-users] Is sqlgrey dead?

[Patrick V. W. <pa...@va...>]

On Sat, 11 Apr 2009 16:25:49 +1200, Michal Ludvig <ml...@lo...>
wrote:
> Bob Apthorpe wrote:
> 
>> I used Net::CIDR if it was there, otherwise I stuck with the
>> existing code
> 
> Aha. In that case the non-Net::CIDR implementation of IPv6 handling
> should be fixed anyway, shouldn't it ;-)
> 
> And once everything works without Net::CIDR there's little point adding
> a dependency on another nonstandard module. Unless it brings features
> not available otherwise of course.
> 
> So -- what do we get from Net::CIDR that we can't have without? The
> point is that sqlgrey shouldn't have unneeded dependencies that only
> make the installation more difficult.

I can see several advantages in using Net::CIDR, beyond the cidrvalidate
functionality.

There is that general advantage of using proven, maintained code vs writing
an application-specific one. If the Perl modules gets a bug fix, so will
your application that depends on it.

Another advantage is regarding the clients_ip_whitelist file and table.
Right now, the read_an_ip_whitelist function only accepts IPv4 ranges that
are either /24 or /32 (or more precisely 3 or 4 octet addresses). This is
kind of broken by today's standards, where mail server farms can sometimes
be spread over /16s. 

With the cidr_lookup function from Net::CIDR, SQLGrey would be able to
process not only to list IPv6 ranges, but also have more flexibility
regarding  prefixes, both for IPv4 and IPv6. One could have specific
prefixes for each IP address range.  This would require to re-write a
number of functions, though. 

As a side note, I kind of solved the latter issue by storing everything in
a Postgresql table which uses the Postgresql cidr data type and adding a
function to SQLGrey to query that table. It is neither clean code nor is it
portable to MySQL or SQLite, because they do not have a similar data type.
Hence, I have not posted it here, but I can send it off-list to whoever is
interested.

Patrick Vande Walle