[arch-dev-public] tcp_wrappers- does anyone actually use it?

[Dan McGee]

On Fri, Sep 10, 2010 at 2:12 AM, Guillaume ALAUX
<guillaume at archlinux.org> wrote:
> On 9 September 2010 19:39, Dan McGee <dpmcgee at gmail.com> wrote:
>> Guys,
>>
>> For the umpteenth time today I stared at ssh wondering why it wasn't
>> accepting incoming connections until I remembered about tcp_wrappers
>> junk, and put the standard "sshd : ALL : allow" line in hosts.allow.
>>
>> Does anyone use this for anything useful at all?
>>
>> 1. The package is now at version 7.6-12 (clearly it is getting a lot
>> of upstream attention)
>> 2. We have 11 patches applied to the package
>> 3. It is inferior to iptables-based filtering
>> 4. It is not very transparent
>>
>> Discussion welcome, but I am raising a vote to remove this dependency
>> from packages currently using it (hopefully this is possible for all
>> 21 of them, http://www.archlinux.org/packages/core/x86_64/tcp_wrappers/)
>> and eventually remove it from core and the repositories.
>>
>> -Dan
>
> Well, I must say it gave me headaches several times especially when
> trying to figure out how to get openldap (and sshd) to work!
>> 4. It is not very transparent
> +1
>
> FYI it looks like we use the "ipv4 only" version whereas there is the
> ipv6-enabled :
> ftp://ftp.porcupine.org/pub/security/index.html
> ftp://ftp.porcupine.org/pub/security/tcp_wrappers_7.6.tar.gz
> ftp://ftp.porcupine.org/pub/security/tcp_wrappers_7.6-ipv6.4.tar.gz
>
> So we are not even "up to date" nor ipv6-compatible !
>
> Adding your other comments, I would vote for a removal of the
> dependencies. Maybe we can still keep the package in our repos in case
> someone explicitly want to use it (in that case we could provide de
> ipv6 version too).

The last updated added the ipv6 patch, so you might want to check your words.

Keeping the package in the repos does no good; it is a shared library
that is most often linked in at compile-time so it needs to be present
if compiled in, and if not, it won't even be looked at.

-Dan