Got very little feedback on this last time...any votes? Saw another thread[1] in the forums today about it causing problems with mpd this time around... -Dan [1] https://bbs.archlinux.org/viewtopic.php?id=109962 On Fri, Sep 10, 2010 at 7:38 AM, Dan McGee <dpmcgee@gmail.com> wrote:
On Fri, Sep 10, 2010 at 2:12 AM, Guillaume ALAUX <guillaume@archlinux.org> wrote:
On 9 September 2010 19:39, Dan McGee <dpmcgee@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