On 20 March 2014 11:34, Lennart Poettering <mzerq...@0pointer.de> wrote:
> Heya! > > I wonder whether it wouldn't be time to say goodbye to tcpwrappers in > Fedora. There has been a request in systemd upstream to disable support > for it by default, but I am not sure I want to do that unless we can > maybe say goodbye to it for the big picture too. > > Why would we get rid of them? > > Well, to make things simpler, primarily. They have not seen any > development since 2003 (that's 11 years I mind you, an eternity in IT). > > I doubt there are many people even using them anymore, firewalls are > more comprehensive and a lot more powerful, and while every admin knows > firewalls, I figure only very few know tcpd/tcpwrap, and even fewer ever > actively make use of them... > > Actually they are used quite a bit in various service worlds. Mainly for ssh and email for dealing with scanners. [DenyHosts is a boon in this area.] The reason for using a secondary tool is that depth of security. Over the years I have found that there are multiple of attacks which will nullify one layer of protection at one point or another. Having a second level or third level of protection is a boon when this happens. At the enterprise level firewalls can come under a different set of change control rules than something like tcpwrappers which is considered application level. While I would like to be able to make a simple change in a firewall, I can end up spending a month until I can. Application controls are usually an hour or so signoff. This means that if tcp-wrappers is going then something will need to be able to replace it to meet that large scale concern. [Automatic firewall controls like firewalld have to be disabled or put into a manual changes only mode in these areas for change control purposes. ] I can't argue on the code maintainability or layout. Not my area of expertise. I can say that if tcpd/libtcpwrappers were to go away that something equivalent would need to be built to replace it for the ability to fine tune at a layer below the firewall. > The API is awful, too, with lot's of open-coded structures, feature > checks in the headers, fixed length strings, globally exported variables, > non-namespaced symbols, really weird exported compatibility wrappers for > OS calls... > > I'd propose we make a clear cut, and just start disabling it in all > services that link to it, instead of letting rot on in Fedora for all > eternity. > > It's bad code, little used, crufty. We have much better stuff now, and > that enables us to say goodbye to the old mess... > > I figure there will be a bit of opposition to this change, thus I > thought I start the discussion on the fedora ML first. Unless there are > major concerns I will propose a feature about this in the next few > days. If somebody wants to join me on this and put his name on the > feature proposal I'd be delighted! > > Lennart > > -- > Lennart Poettering, Red Hat > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel > Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- Stephen J Smoogen.
-- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
