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...
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
On Thu, 20 Mar 2014, Lennart Poettering wrote:
I wonder whether it wouldn't be time to say goodbye to tcpwrappers in Fedora.
I'd be happy to see those go.
Those who depend on it though, should see some "failed closed" behaviour, so their service does not suddenly become more exposed.
Paul
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 03/20/2014 11:59 AM, Paul Wouters wrote:
On Thu, 20 Mar 2014, Lennart Poettering wrote:
I wonder whether it wouldn't be time to say goodbye to tcpwrappers in Fedora.
I'd be happy to see those go.
Those who depend on it though, should see some "failed closed" behaviour, so their service does not suddenly become more exposed.
Paul
Yeah I am not sure you are going to be able to make a totally clean cut, there are some of us out there who still use this and it works, despite however much crap it is underneath the covers.
A fail closed would be a decent first step, but as I said dropping it altogether without some mitigation would be a bad move I believe.
Just my two cents,
- -Erinn
On Thu, 20.03.14 13:59, Paul Wouters (paul@nohats.ca) wrote:
Those who depend on it though, should see some "failed closed" behaviour, so their service does not suddenly become more exposed.
Well, this sounds like something to cover in the release notes, plus a check in fedup or so that tells people about this should /etc/hosts.{allow,deny} have changed from shipped defaults or so.
Lennart
2014-03-20 18:59 GMT+01:00 Paul Wouters paul@nohats.ca:
On Thu, 20 Mar 2014, Lennart Poettering wrote:
I wonder whether it wouldn't be time to say goodbye to tcpwrappers in
Fedora.
I'd be happy to see those go.
Those who depend on it though, should see some "failed closed" behaviour, so their service does not suddenly become more exposed.
Wouldn't failing closed essentially involve keeping libwrap, keeping all the callers, keeping the existing parser, only ignoring most of the rule and treating any rule matching the daemon name as DENY? At that point we might just as well keep the non-controversially-safe functionality like IP checks working. Mirek
On 20 March 2014 11:34, Lennart Poettering mzerqung@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
On Thu, 20.03.14 12:20, Stephen John Smoogen (smooge@gmail.com) wrote:
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.
Well, all mails servers as well as sshd have much better ways to do such filtering. sshd has "Match", Postfix for example has "smtpd_client_restrictions=", and so on.
Again, I have no doubt that some people still use tcpwrappers. But I'd argue that is clearly the excpetion, not the rule, and they'd better use something different, and that we should be creating an excellent distro, instead of a one that features horrible software...
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.
Well, it certainly makes sense to combine a firewall with let's say selinux with maybe postfix/ssh acls. Then you already have three layers of protection, of very good protection. But of all possible options tcpwrap is the absolute worst choice. And we should be able to deprecate and remove stuff from our core OS if we think it is crap.
I mean, there are two sides of the medal: sure multiple layers of protection might be a good thing, but you also make things a lot more complex with each one, and you involve more possibly exploitable code -- and tcpwrap is simply bad code, that's a fact. So you have to balance things out: is something a layer that is worth the trouble? Or does having it around make things worse? I am of the opinion that tcpwrap indeed does make things worse.
Sure, three layers of condoms probably make sex safer, but then again, if one of them is made of 10 year old half-decomposed goat intestines, then maybe the sex is a lot less fun, too...
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. ]
Well, that really sounds like a specific issue of your company... Really, I don't think the question whether the bureaucracy of some hypothetical company makes a distinction between tcwrap and firewalls has no place in the discussion whether we should support tcpwrap in our distro or not.
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.
Why? Other than your hypothetical bureaucracy, is there anything that tcpwrap can do that firewalls can't do, that really deserves to be supported? I really can't see anything... [1]
tcpd comes from a time when there weren't local firewalls available in all Unix systems, so they built something like them in userspace. But that time is long long gone, and pretty much any Linux installation I know nowadays has a firewall compiled into the kernel...
Lennart
[1] well, sure tcpwrap resolves DNS dynamically and can use that for access control, but people who bind access control to DNS really should find a different job than administrator...
On 20 March 2014 13:05, Lennart Poettering mzerqung@0pointer.de wrote:
On Thu, 20.03.14 12:20, Stephen John Smoogen (smooge@gmail.com) wrote:
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.
Well, all mails servers as well as sshd have much better ways to do such filtering. sshd has "Match", Postfix for example has "smtpd_client_restrictions=", and so on.
And now I need to have X number applications special syntax to whitelist/blacklist a site. I need to change X files to make that change. Each of those could be a separate change control process depending on the size of the organization. Or I have 1 file that I can make a change to which has usually one syntax and one set of reviews.
Again, I have no doubt that some people still use tcpwrappers. But I'd argue that is clearly the excpetion, not the rule, and they'd better use something different, and that we should be creating an excellent distro, instead of a one that features horrible software...
Look I am not saying it isn't horrible to look at from a coding side. From a systems administrators side it does stuff in a very clean, easily audited way. It is also a nice key place where every application is actually using the same syntax versus each custom version. Having spent several ITIL meetings where you have to explain the syntax of each application to non-sysadmins, then prove that the change is correct, then prove that the change is easily backed out, and then other parts.. having 1 syntax to do that versus doing every applications custom version makes it a lot easier to deal with.
I am not saying rip it out, but I am saying that you need something that replaces that one syntax, one file control, simple syntax method.
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.
Well, it certainly makes sense to combine a firewall with let's say selinux with maybe postfix/ssh acls. Then you already have three layers of protection, of very good protection. But of all possible options tcpwrap is the absolute worst choice. And we should be able to deprecate and remove stuff from our core OS if we think it is crap.
I mean, there are two sides of the medal: sure multiple layers of protection might be a good thing, but you also make things a lot more complex with each one, and you involve more possibly exploitable code -- and tcpwrap is simply bad code, that's a fact. So you have to balance things out: is something a layer that is worth the trouble? Or does having it around make things worse? I am of the opinion that tcpwrap indeed does make things worse.
Sure, three layers of condoms probably make sex safer, but then again, if one of them is made of 10 year old half-decomposed goat intestines, then maybe the sex is a lot less fun, too...
I don't see the need to make such crude references.
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. ]
Well, that really sounds like a specific issue of your company... Really, I don't think the question whether the bureaucracy of some hypothetical company makes a distinction between tcwrap and firewalls has no place in the discussion whether we should support tcpwrap in our distro or not.
I am giving you a standard enterprise problem. You are constantly going on about how systemd solves enterprise level problems and enterprises will love them. I am giving you a standard problem that tcpwrappers solves and you need to come up with some sort of replacement for them. Most real problems enterprise administrators deal with are people oriented and this is a tool which deals with those problems in a way that is clean and clear.
All I am trying to do is point them out to you so that you don't end up having to spend all of 2016 recoding a replacement because it became a deal breaker for the various enterprise downstreams. If you want to make this a "You dare question me?" then fine, I can go do something else and know in the future that you aren't really looking for feedback.
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.
Why? Other than your hypothetical bureaucracy, is there anything that tcpwrap can do that firewalls can't do, that really deserves to be supported? I really can't see anything... [1]
I never rely on dns in hosts.allow or .deny. I use just ip addresses. So I don't see what [0] has on this.
tcpd comes from a time when there weren't local firewalls available in all Unix systems, so they built something like them in userspace. But that time is long long gone, and pretty much any Linux installation I know nowadays has a firewall compiled into the kernel...
Lennart
[1] well, sure tcpwrap resolves DNS dynamically and can use that for access control, but people who bind access control to DNS really should find a different job than administrator...
-- 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
On Thu, 20.03.14 13:44, Stephen John Smoogen (smooge@gmail.com) wrote:
Well, all mails servers as well as sshd have much better ways to do such filtering. sshd has "Match", Postfix for example has "smtpd_client_restrictions=", and so on.
And now I need to have X number applications special syntax to whitelist/blacklist a site. I need to change X files to make that change. Each of those could be a separate change control process depending on the size of the organization. Or I have 1 file that I can make a change to which has usually one syntax and one set of reviews.
Well, if you filter in postfix or ssh, then you have a domain-specific, powerful language there. You can not only match on source addresses, but also on user names, groups, authentication methods, connection features SASL schemes, crypto algorithms, ... It's a very good thing being able to control this in a unified, but domain-specific way. There are also proper firewalls, for traffic-level filtering. But where's the place for tcpwrappers in all of this? It's neither really generic, nor domain-specific, and also crappy code. We really don't need 3 layers checking the very same thing...
postfix and sshd have mechanisms to filter for on specific domain each, however covering a multitude of domain-specific high-level, matches and actions.
A firewall has mechanisms to filter for all domains, however only covering a smaller number of generic, low-level matches and actions.
tcpwrap otoh is somewhere in the middle, it's neither really generic, nor really powerful. It's not a convincing, a very redundant option, since it gets you very little features on top of a firewall, and is not that universal either.
Look I am not saying it isn't horrible to look at from a coding side. From a systems administrators side it does stuff in a very clean, easily audited way. It is also a nice key place where every application is actually using the same syntax versus each custom version. Having spent several ITIL meetings where you have to explain the syntax of each application to non-sysadmins, then prove that the change is correct, then prove that the change is easily backed out, and then other parts.. having 1 syntax to do that versus doing every applications custom version makes it a lot easier to deal with.
If you want that unified language that can actually cover all kinds of apps and traffic, then use a firewall. It is truly universal (unlike tcpwrappers), and at least as powerful...
I am not saying rip it out, but I am saying that you need something that replaces that one syntax, one file control, simple syntax method.
Let that be the firewall. It does the same thing, just better.
I am giving you a standard enterprise problem. You are constantly going on about how systemd solves enterprise level problems and enterprises will love them. I am giving you a standard problem that tcpwrappers solves and you need to come up with some sort of replacement for them. Most real problems enterprise administrators deal with are people oriented and this is a tool which deals with those problems in a way that is clean and clear.
Yupp, here's my replacement: a proper firewall.
And no, it's not a standard enterprise problem that firewalls need higher people's sign-off than tcpwrappers in your theoretic firewall..
All I am trying to do is point them out to you so that you don't end up having to spend all of 2016 recoding a replacement because it became a deal breaker for the various enterprise downstreams. If you want to make this a "You dare question me?" then fine, I can go do something else and know in the future that you aren't really looking for feedback.
You know, we have more powerful replacements both high-level (in postfix, sshd, ...) and lower-level, we really don't need tcp wrappers.
I posted this here for feedback, and yes I got it, please understand though at I will at least try to convince you that tcpwrap is a dead-end. I mean, take it as an indication that I am actually taking your feedback seriously, that I spend a lot of time arguing against it. If I wouldn't take it seriously I wouldn't have started this discussion and would certainly not have replied to this message...
Lennart
Am 21.03.2014 01:00, schrieb Lennart Poettering:
On Thu, 20.03.14 13:44, Stephen John Smoogen (smooge@gmail.com) wrote:
Well, all mails servers as well as sshd have much better ways to do such filtering. sshd has "Match", Postfix for example has "smtpd_client_restrictions=", and so on.
And now I need to have X number applications special syntax to whitelist/blacklist a site. I need to change X files to make that change. Each of those could be a separate change control process depending on the size of the organization. Or I have 1 file that I can make a change to which has usually one syntax and one set of reviews.
Well, if you filter in postfix or ssh, then you have a domain-specific, powerful language there. You can not only match on source addresses, but also on user names, groups, authentication methods, connection features SASL schemes, crypto algorithms
what has this to do with "I have 1 file that I can make a change to which has usually one syntax and one set of reviews"?
On Thu, Mar 20, 2014 at 8:00 PM, Lennart Poettering mzerqung@0pointer.dewrote:
A firewall has mechanisms to filter for all domains, however only covering a smaller number of generic, low-level matches and actions.
From a usability PoV, /etc/hosts.{allow,deny} is good. I wonder if teaching
firewalld to support some of that functionality would help here.
cheers,
m
On Thu, Mar 20, 2014 at 8:04 PM, Martin Langhoff martin.langhoff@gmail.comwrote:
On Thu, Mar 20, 2014 at 8:00 PM, Lennart Poettering mzerqung@0pointer.dewrote:
A firewall has mechanisms to filter for all domains, however only covering a smaller number of generic, low-level matches and actions.
From a usability PoV, /etc/hosts.{allow,deny} is good. I wonder if teaching firewalld to support some of that functionality would help here.
To clarify: what I mean is that firewalld could parse the legacy files, interpreting the rules that are translatable, failing safely for those that are are not.
cheers,
m
On Thu, 20.03.14 20:04, Martin Langhoff (martin.langhoff@gmail.com) wrote:
On Thu, Mar 20, 2014 at 8:00 PM, Lennart Poettering mzerqung@0pointer.dewrote:
A firewall has mechanisms to filter for all domains, however only covering a smaller number of generic, low-level matches and actions.
From a usability PoV, /etc/hosts.{allow,deny} is good. I wonder if teaching firewalld to support some of that functionality would help here.
I don't see how these files would have a good "usability". It has all this fancy support for good old IDENT user names!
I mean, in this day and age we should not consider an ACL language well designed if it basically pushes users to use IDENT and DNS for authentication. (And no, don't say the words DNSSEC, nobody sets that up, we don't have it as default, and tcpwrap doesn't check wether DNSSEC is enabled either, before trusting a hostname...).
Quite frankly, about 70% of tcpwrappers is security theater. It gives you a fake sense of security with DNS and IDENT checks and that kind of stuff.
The other 30% (i.e. simple IP range checks), are much better done in a real firewall.
An no, a language designed like that doesn't have good usability. Somebody who is new to all of this, and reads the man page will set up matches against DNS names and IDENT, and then feel secure. That's doesn't provide good "usability", that's simply misleading the user. Giving a promise of security, while being completely conceptually broken and easily compromisable, if working at all...
BTW, I asked the other distros about this. ArchLinux has removed tcpwrap from their distro 2 years ago. Suse is making babysteps for removing it (the original patch to disable it by default in systemd came from them). Debian (of course...) loves it though.
Lennart
On Fri, 21 Mar 2014, Lennart Poettering wrote:
I mean, in this day and age we should not consider an ACL language well designed if it basically pushes users to use IDENT and DNS for authentication. (And no, don't say the words DNSSEC, nobody sets that up, we don't have it as default, and tcpwrap doesn't check wether DNSSEC is enabled either, before trusting a hostname...).
we kinda do have dnssec per default. All DNS servers installed per default do DNSSEC. Installing dnssec-trigger makes that even more pervasive.
But I agree decisions based on DNS/reverse and IDENT are long dead.
The other 30% (i.e. simple IP range checks), are much better done in a real firewall.
I agree.
Paul
On Fri, 21.03.14 00:27, Paul Wouters (paul@nohats.ca) wrote:
On Fri, 21 Mar 2014, Lennart Poettering wrote:
I mean, in this day and age we should not consider an ACL language well designed if it basically pushes users to use IDENT and DNS for authentication. (And no, don't say the words DNSSEC, nobody sets that up, we don't have it as default, and tcpwrap doesn't check wether DNSSEC is enabled either, before trusting a hostname...).
we kinda do have dnssec per default. All DNS servers installed per default do DNSSEC. Installing dnssec-trigger makes that even more pervasive.
Well, but glibc can't do the DNSSEC client side, can it?
Lennart
On Fri, 21 Mar 2014, Lennart Poettering wrote:
we kinda do have dnssec per default. All DNS servers installed per default do DNSSEC. Installing dnssec-trigger makes that even more pervasive.
Well, but glibc can't do the DNSSEC client side, can it?
Applications that want to do DNSSEC validation can use one of the dns libraries available (libunbound, libisc, ldns, libval) or their python/perl bindings. Or they can trust the system and depend on the AD bit from a locally running nameserver.
Some progress is being made elsewhere to come up with an API that's somewhere in the middle between blind AD bit trust and running a full dnssec cache in the application, eg getdns api:
https://bugzilla.redhat.com/show_bug.cgi?id=1070510
In addition to making it easier to get all the records in one go to do validation and then throw away the intermediate data:
https://tools.ietf.org/html/draft-wouters-edns-chain-query-00
There is still a larger discussion going on about how exactly to fit DNSSEC in the OS and applications. Some people don't like blind trust, some people don't tying the application too tightly to DNSSEC. But with TLSA records in DNS, there is now a need to add DNSSEC to crypto libraries.
Paul
On Fri, 21.03.14 12:37, Paul Wouters (paul@nohats.ca) wrote:
On Fri, 21 Mar 2014, Lennart Poettering wrote:
we kinda do have dnssec per default. All DNS servers installed per default do DNSSEC. Installing dnssec-trigger makes that even more pervasive.
Well, but glibc can't do the DNSSEC client side, can it?
Applications that want to do DNSSEC validation can use one of the dns libraries available (libunbound, libisc, ldns, libval) or their python/perl bindings. Or they can trust the system and depend on the AD bit from a locally running nameserver.
Well, but tcpd doesn't use that.
As long as -lresolve (i.e. glibc and getaddrinfo()) can't do DNSSEC it's just not there...
Some progress is being made elsewhere to come up with an API that's somewhere in the middle between blind AD bit trust and running a full dnssec cache in the application, eg getdns api:
Ah, yet another DNS API... Because we have so few... A library with an API of getdns_list_create_with_extended_memory_functions() looks really promising... not!
Lennart
On Fri, 21 Mar 2014, Lennart Poettering wrote:
As long as -lresolve (i.e. glibc and getaddrinfo()) can't do DNSSEC it's just not there...
You are proposing changing the api of getaddrinfo()? Could luck with that?
Yes, applications that want to see DNSSEC results will have to do a little bit of extra work. It's not the end of the world. Applications that only care about the DNS being protected should just continue their current API, and hopefully resolv.conf points to localhost so the local DNS server will return ServFail's to the applications for spoofed DNS.
Some progress is being made elsewhere to come up with an API that's somewhere in the middle between blind AD bit trust and running a full dnssec cache in the application, eg getdns api:
Ah, yet another DNS API... Because we have so few... A library with an API of getdns_list_create_with_extended_memory_functions() looks really promising... not!
It's built on top of libunbound. You can use libunbound directly.
Paul
On Fri, 21.03.14 13:05, Paul Wouters (paul@nohats.ca) wrote:
On Fri, 21 Mar 2014, Lennart Poettering wrote:
As long as -lresolve (i.e. glibc and getaddrinfo()) can't do DNSSEC it's just not there...
You are proposing changing the api of getaddrinfo()? Could luck with that?
Dunno, it doesn't sound too difficult to add a new flag .ai_flags that indicates whether the dns data has been verified locally or so...
Lennart
2014-03-21 1:00 GMT+01:00 Lennart Poettering mzerqung@0pointer.de:
On Thu, 20.03.14 13:44, Stephen John Smoogen (smooge@gmail.com) wrote:
And now I need to have X number applications special syntax to whitelist/blacklist a site. I need to change X files to make that change. Each of those could be a separate change control process depending on the size of the organization. Or I have 1 file that I can make a change to which has usually one syntax and one set of reviews.
Well, if you filter in postfix or ssh, then you have a domain-specific, powerful language there. You can not only match on source addresses, but also on user names, groups, authentication methods, connection features SASL schemes, crypto algorithms, ... It's a very good thing being able to control this in a unified, but domain-specific way.
What's "unified" about that?
Also, most of the things you mention should be up to administrator's policy decision ("what authentication method or crypto is accepted") but not really subnet- or domain-specific. As a heuristic, "If you can't build a reasonable GUI for it, you can't explain it or validate it and it will be misunderstood." (... that heuristic would kill so much of our servers' options :) )
If you want that unified language that can actually cover all kinds of apps and traffic, then use a firewall. It is truly universal (unlike tcpwrappers), and at least as powerful...
Using firewall with RPC services is possible but essentially defeats the point of portmap, which is to avoid using dynamically allocated IP port numbers and to instead use protocol / RPC references.
DNS queries can't really be done within the firewall (and due to the circular dependency between having the firewall up before allowing access to the network and needing access to the network to resolve DNS names, they can't even be used in the on-disk firewall configuration). Having a single centralized name->IP address repository instead of having a redundant copy in each host, and having the configuration use readable names instead of IP addresses, makes some difference in usability and management overhead.
Also, note that an organization *can* actually make DNS sufficiently secure by using their own DNS servers that have authoritative sources for the relevant domains, even without DNSSEC: this would keep out all script kiddies and internet-originating attackers who can't attack the link between the tcp_wrappers user and the DNS server, while still allowing attacks from a compromised computer within the organization--which is *exactly* the case where the domain-specific configuration would probably allow access *anyway*, so the attacker might have nothing to gain by subverting DNS. (Yes, there are many possible configurations of tcp_wrappers where this argument does not apply, and it does require care from the administrators of the system.)
The RHEL documentation, apart from fully describing the abilities, specifically describes two uses: a ftpd banner, and running arbitrary shell to collect intrusion detection statistics. Neither is reasonably easy to do with the firewall. Now I'm not saying that these specific features are critical :)
We *do* need to *actually understand* the user's motivations for using tcp_wrappers, not just dismiss it as security theater--because even if it *were* security theater, if we don't know why the users are doing this they are likely to do it in the new system as well, and we will end up with even a bigger mess implementing the same security theater. Mirek
On Sat, 22.03.14 01:20, Miloslav Trmač (mitr@volny.cz) wrote:
Well, if you filter in postfix or ssh, then you have a domain-specific, powerful language there. You can not only match on source addresses, but also on user names, groups, authentication methods, connection features SASL schemes, crypto algorithms, ... It's a very good thing being able to control this in a unified, but domain-specific way.
What's "unified" about that?
Isn't that obvious? You have a single language that centralizes your access decisions in one place and opens up to you a variety of credentials from all layers of the stack. And not just IP range decisions...
DNS queries can't really be done within the firewall (and due to the circular dependency between having the firewall up before allowing access to the network and needing access to the network to resolve DNS names, they can't even be used in the on-disk firewall configuration). Having a single centralized name->IP address repository instead of having a redundant copy in each host, and having the configuration use readable names instead of IP addresses, makes some difference in usability and management overhead.
This is supposedly security functionality. You shouldn't build your security functionality on top of DNS. If you do, then you gain no security.
Also, note that an organization *can* actually make DNS sufficiently secure by using their own DNS servers that have authoritative sources for the relevant domains, even without DNSSEC: this would keep out all script kiddies and internet-originating attackers who can't attack the link between the tcp_wrappers user and the DNS server, while still allowing attacks from a compromised computer within the organization--which is *exactly* the case where the domain-specific configuration would probably allow access *anyway*, so the attacker might have nothing to gain by subverting DNS. (Yes, there are many possible configurations of tcp_wrappers where this argument does not apply, and it does require care from the administrators of the system.)
And you honestly believe that people who are capable enough of setting up DNS locally and across the company in a secure way to do something like this, are also crazy enough to do their access control with tcpwrap rather maybe firewalls and basically every other possibility?
Or, maybe there are people like that, there's always somebody crazy enough for everything. But then the question is: should our product be a toolbox with lots of crappy tools who are excessively hard to use in a secure way, even though they are supposedly security tools, only useful for extraordinarily capable administrators, who know exactly what they have to make of them, and know that their supposedly "simple" configuration files are really insecure unless you also are willing to set up a massively complicated infrastructure of DNSSEC or otherwise secured links so that nobody can poison your DNS?
You guys claim on one hand that tcpwrap is wonderfully designed and super-easy to use. On the other hand you advise people using it to set up DNSSEC, secured links and whatnot... So what is it now? Secure? Not secure? Easy to setup? Difficult to set up?
We *do* need to *actually understand* the user's motivations for using tcp_wrappers, not just dismiss it as security theater--because even if it *were* security theater, if we don't know why the users are doing this they are likely to do it in the new system as well, and we will end up with even a bigger mess implementing the same security theater.
We *do* know that tcpd is 70% insecure non-sense, 100% crappy code, and about 30% logic that is much better, safer, and more comprehensively implemented in a firewall.
Lennart
2014-03-22 3:21 GMT+01:00 Lennart Poettering mzerqung@0pointer.de:
On Sat, 22.03.14 01:20, Miloslav Trmač (mitr@volny.cz) wrote:
Well, if you filter in postfix or ssh, then you have a domain-specific, powerful language there. You can not only match on source addresses,
but
also on user names, groups, authentication methods, connection features SASL schemes, crypto algorithms, ... It's a very good thing being able to control this in a unified, but domain-specific way.
What's "unified" about that?
Isn't that obvious? You have a single language that centralizes your access decisions in one place
I see what you mean now. There are two mutually exclusive dimensions to unify here (same for all servers / everything for one server); so it is unordered which one is "more unified".
This is supposedly security functionality. You shouldn't build your
security functionality on top of DNS. If you do, then you gain no security.
I have made a careful argument (quoted below). Feel free to refute that argument with specific objections instead of general guidelines like "you shouldn't use DNS" that border on cargo-cult security.
Also, note that an organization *can* actually make DNS sufficiently
secure
by using their own DNS servers that have authoritative sources for the relevant domains, even without DNSSEC: this would keep out all script kiddies and internet-originating attackers who can't attack the link between the tcp_wrappers user and the DNS server, while still allowing attacks from a compromised computer within the organization--which is *exactly* the case where the domain-specific configuration would probably allow access *anyway*, so the attacker might have nothing to gain by subverting DNS. (Yes, there are many possible configurations of tcp_wrappers where this argument does not apply, and it does require care from the administrators of the system.)
And you honestly believe that people who are capable enough of setting up DNS locally and across the company in a secure way to do something like this,
The design I have described does not require *an*y special effort to secure DNS; no DNSSec, no VPNs, no nothing. Just use ordinary wired Ethernet, and WPA2 for your WiFi, the way everyone already does. (The trouble with this design is not that it is difficult to set up, but that it doesn't mean every possible configuration that uses DNS is reliable.)
Specifically, basically any small business with a single internal network and a single Linux do-it-all box (which includes a DNS server for the internal network) can AFAICT quite safely use tcp_wrappers to restrict access to some services of the server to the internal network.
are also crazy enough to do their access control with tcpwrap
rather maybe firewalls and basically every other possibility?
Saying that they would be crazy to use it in a thread that is explicitly discussing whether there are reasonable uses is circular reasoning.
You guys claim on one hand that tcpwrap is wonderfully designed and
super-easy to use.
I don't remember anybody claiming that; paying a little more attention to what people are actually saying might help mutual understanding.
We *do* need to *actually understand* the user's motivations for using
tcp_wrappers, not just dismiss it as security theater--because even if it *were* security theater, if we don't know why the users are doing this
they
are likely to do it in the new system as well, and we will end up with
even
a bigger mess implementing the same security theater.
We *do* know that tcpd is 70% insecure non-sense, 100% crappy code, and about 30% logic that is much better, safer, and more comprehensively implemented in a firewall.
I'm not in this thread to discuss technical merits of the existing implementation. It may be 100% crappy code. *All* of what you say above may be true, but that being true about a widely-used feature *doesn't automatically mean that eliminating the feature increases securit*y.
I'm not even in this thread to object to doing extra work to break users' systems, because you may be right that most users of tcp_wrappers that use it for the DNS functionality shouldn't, and it might be irresponsible for us to support such configurations.
I'm participating in this discussion because, as a general rule, I assume most administrators configuring security, and most users in general, *aren't idiots*. So, the fairly large number of assumed non-idiots using this functionality suggests, as a first approximation to truth, that it is useful, and it's the few of us that discuss removal of the feature that are wrong about the consequences of our actions.
If this is being used (and AFAICT it is), then the users have a reason. Per the general rule, that reason is likely to be right for their situation; and even if they shouldn't be using it, their thought process is likely to be rational, only based on some incorrect assumption. *Why* are administrators using this?
If they could be using the firewall and are using hosts_access instead, why? If they are using DNS-based rules, why? (If they are using ident, why? Well, let's assume that the precondition is false and skip this :) )
If we don't know, how can we expect to improve security by removing this functionality? Either the users were right to use this, and they will be hurt by the removal, or they were wrong but will apply the same incorrect assumption to something else.
Alternatively, feel free to assume that most users of tcp_wrappers are mistaken; what are they mistaken about, what do we need to fix in the tools or documentation so that they actually start designing their networks and using their systems securely?
If we remove tcp_wrappers, we should expect the users to want to preserve the existing functionality--migrating existing tested configuration to a different file is far easier than designing different security controls. So, users will probably take their existing, secure or insecure, hosts_access rules, and move them as they are, secure or insecure, into application-specific configuration (your "basically every other possibility"). In such case, quite a few Fedora developers would have done extra work, many users would have done extra work, and *nothing* would have improved about security of the system; on the contrary, we would only have the additional problems of many independent slightly differing implementations.
*Why* are people using this? Mirek
2014-03-22 5:20 GMT+01:00 Miloslav Trmač mitr@volny.cz:
I'm participating in this discussion because, as a general rule, I assume most administrators configuring security, and most users in general, *aren't idiots*. So, the fairly large number of assumed non-idiots using this functionality suggests, as a first approximation to truth, that it is useful, and it's the few of us that discuss removal of the feature that are wrong about the consequences of our actions.
... and this equally applies to all the programmers who wrote servers that don't call tcp_wrappers but provide similar DNS-based policy mechanisms.
On 03/22/2014 04:20 AM, Miloslav Trmač wrote:
I'm not in this thread to discuss technical merits of the existing implementation. It may be 100% crappy code. /All/ of what you say above may be true, but that being true about a widely-used feature /doesn't automatically mean that eliminating the feature increases securit/y.
I'm not even in this thread to object to doing extra work to break users' systems, because you may be right that most users of tcp_wrappers that use it for the DNS functionality shouldn't, and it might be irresponsible for us to support such configurations.
I'm participating in this discussion because, as a general rule, I assume most administrators configuring security, and most users in general, /aren't idiots/. So, the fairly large number of assumed non-idiots using this functionality suggests, as a first approximation to truth, that it is useful, and it's the few of us that discuss removal of the feature that are wrong about the consequences of our actions.
So here's the thing daemons and applications are inconsistent in their support for libwrap like for example sshd supports it while smbd does not which leads to incorrect configuration and administrative expectation which in itself poses a security risk.
The only way administrator can figure out which daemon/service was built with libwrap support, is via ldd/string grep magic since we as an distribution have not provide them with a list which do support it and which do not,nor do we have those component correctly depend on libwrap.so.0.
The undisputed fact is you are truly better off security and performance wize using netfilter to solve this which can be done via tcp-wrapper like behavior so...
iptables -A INPUT -p tcp --dport <port> -m iprange --src-range <ip-range>-<iprange> -j ACCEPT iptables -A INPUT -p tcp --dport <port> -j DROP
We should have dropped tcp-wrappers as well as denyhosts etc. a long time ago but you know old habits die hard and all that but if FESCo is going to refuse to do that it should ensure at least there will be a list which explains it to adminstrators which component support this and proper package dependency on libwrab for administrators sanity and expectations...
JBG
On Sat, Mar 22, 2014 at 10:04:51AM +0000, "Jóhann B. Guðmundsson" wrote:
So here's the thing daemons and applications are inconsistent in their support for libwrap like for example sshd supports it while smbd does not which leads to incorrect configuration and administrative expectation which in itself poses a security risk.
That's an excellent point; inconsistency across the distribution is definitely points-off for tcp wrappers.
The only way administrator can figure out which daemon/service was built with libwrap support, is via ldd/string grep magic since we as an distribution have not provide them with a list which do support it and which do not,nor do we have those component correctly depend on libwrap.so.0.
Can you point to an example of this? Since it is a compiled dynamic library, RPM's automatic dependency checking should get this. Try `repoquery --whatrequires tcp_wrappers-libs`.
Speaking of inconsistency, I notice syslog-ng in that list but not rsyslogd. (And as previously noted, there's sendmail and exim, but not postfix.)
Jóhann B. Guðmundsson wrote:
So here's the thing daemons and applications are inconsistent in their support for libwrap like for example sshd supports it while smbd does not which leads to incorrect configuration and administrative expectation which in itself poses a security risk.
I don't buy that argument.
In particular, don't let perfect be the enemy of good, ie, if libwrap isn't perfect => get rid of it, isn't a logical conclusion here (for *this* particular reason at least).
-- Rex
Am 22.03.2014 03:21, schrieb Lennart Poettering:
On Sat, 22.03.14 01:20, Miloslav Trmač (mitr@volny.cz) wrote:
DNS queries can't really be done within the firewall (and due to the circular dependency between having the firewall up before allowing access to the network and needing access to the network to resolve DNS names, they can't even be used in the on-disk firewall configuration). Having a single centralized name->IP address repository instead of having a redundant copy in each host, and having the configuration use readable names instead of IP addresses, makes some difference in usability and management overhead.
This is supposedly security functionality. You shouldn't build your security functionality on top of DNS. If you do, then you gain no security
in your world one thing rules all true in the world of *layered* security not true
Am 22.03.2014 07:15, schrieb Reindl Harald:
Am 22.03.2014 03:21, schrieb Lennart Poettering:
On Sat, 22.03.14 01:20, Miloslav Trmač (mitr@volny.cz) wrote:
DNS queries can't really be done within the firewall (and due to the circular dependency between having the firewall up before allowing access to the network and needing access to the network to resolve DNS names, they can't even be used in the on-disk firewall configuration). Having a single centralized name->IP address repository instead of having a redundant copy in each host, and having the configuration use readable names instead of IP addresses, makes some difference in usability and management overhead.
This is supposedly security functionality. You shouldn't build your security functionality on top of DNS. If you do, then you gain no security
in your world one thing rules all true in the world of *layered* security not true
and i will give an example what layered security means
* years ago played around with SELinux * after boot SELinux blocked iptables to start * my smb.conf has "hosts allow" on any machine * i recognized the failed iptables by messages in the samba log about not allowed hosts * guess what happens if you have a guest-share in that case without another security layer
so if you propose to remove things which really may not be the best soultion but are a solution in context of layered security you should at the same time propose a replacement which does it better - in context of tcpwrappers a replacement wokring with hosts.allow and hosts.deny and go ahead propose this to be linked with any network aware software in the distribution
*that* would be a smart proposal and gains a lot
propose to declare things as deprectated while demand from the whole world adopt the changes is a sloppy attitude, frankly can you imagine what people all over the world could have developed on top of Fedora with the time wasted the last few years by adopt changes with no backward compatibility?
make proposals and deprecations is easy as long the person who does has not to chew the result by cherry picking what makes the own development easier and cleaner and not care about existing usecases just working until someone breaks them willingly
and *please* as long as you don't understand layered security and think a single point of defense resulting in a single point of failure with no additional safety net don't talk too much about security
Le Sam 22 mars 2014 03:21, Lennart Poettering a écrit :
And you honestly believe that people who are capable enough of setting up DNS locally and across the company in a secure way to do something
To set up DNS securely you need a handful of people to manage a master dns and its slave on the internal network, and order every one else to use them only.
To set up filtering rules you need someone for each handful of servers, and with virtualization, that's not the same kind of number at all. Apps sprout up like mushrooms after rain, they change all the time, they conflict with each other, just conveying information from the development teams to the security people is a full time job. Something that is widely understood and can be done by rote by less-clueful people to harden things a bit is not to be spurned.
Regards,
Le Sam 22 mars 2014 01:20, Miloslav Trmač a écrit :
The RHEL documentation, apart from fully describing the abilities, specifically describes two uses: a ftpd banner
Surprisingly, ftp is still widely used entreprise-side, because ssh is giving too much access, and no one released an easy to use webdav substitute (plus windows dav clients suck)
Regards,
Am 24.03.2014 12:57, schrieb Nicolas Mailhot:
Le Sam 22 mars 2014 01:20, Miloslav Trmač a écrit :
The RHEL documentation, apart from fully describing the abilities, specifically describes two uses: a ftpd banner
Surprisingly, ftp is still widely used entreprise-side, because ssh is giving too much access
no, it is easy to restrict ssh to ONLY sftp and chroot and with simple bind-mounts you can completly replace ftp, doing that here in production over years with 3 simple scripts
[root@localhost:~]$ mount | grep sftp-homes | wc -l 168
* create and maintain the mountpoints from the backend * mount all bind-mounts at boot * unmount them before shutdown * internally you can use the same for userbased smb shares
that's why i go that angry by the broken coreutils "df" behavior which now luckily no longer lists all bind-mounts but is still a mess and nobody cares
https://bugzilla.redhat.com/show_bug.cgi?id=1042840 https://bugzilla.redhat.com/show_bug.cgi?id=1001092#c12
On 03/24/2014 01:06 PM, Reindl Harald wrote:
Am 24.03.2014 12:57, schrieb Nicolas Mailhot:
Le Sam 22 mars 2014 01:20, Miloslav Trmač a écrit :
The RHEL documentation, apart from fully describing the abilities, specifically describes two uses: a ftpd banner
Surprisingly, ftp is still widely used entreprise-side, because ssh is giving too much access
no, it is easy to restrict ssh to ONLY sftp and chroot and with simple bind-mounts you can completly replace ftp, doing that here in production over years with 3 simple scripts
It's still very difficult to securely process uploaded files under a different user account. Some SFTP clients set restrictive permissions on upload, and the OpenSSH implementation does not allow to bypass that.
Am 24.03.2014 13:21, schrieb Florian Weimer:
On 03/24/2014 01:06 PM, Reindl Harald wrote:
Am 24.03.2014 12:57, schrieb Nicolas Mailhot:
Le Sam 22 mars 2014 01:20, Miloslav Trmač a écrit :
The RHEL documentation, apart from fully describing the abilities, specifically describes two uses: a ftpd banner
Surprisingly, ftp is still widely used entreprise-side, because ssh is giving too much access
no, it is easy to restrict ssh to ONLY sftp and chroot and with simple bind-mounts you can completly replace ftp, doing that here in production over years with 3 simple scripts
It's still very difficult to securely process uploaded files under a different user account. Some SFTP clients set restrictive permissions on upload, and the OpenSSH implementation does not allow to bypass that.
man umask
[root@rh:/downloads]$ cat /etc/ssh/sshd_config | grep internal-sftp Subsystem sftp internal-sftp -u 006
On 03/24/2014 01:23 PM, Reindl Harald wrote:
It's still very difficult to securely process uploaded files under a different user account. Some SFTP clients set restrictive permissions on upload, and the OpenSSH implementation does not allow to bypass that.
man umask
[root@rh:/downloads]$ cat /etc/ssh/sshd_config | grep internal-sftp Subsystem sftp internal-sftp -u 006
umask doesn't apply to explicit chmod.
Am 24.03.2014 13:26, schrieb Florian Weimer:
On 03/24/2014 01:23 PM, Reindl Harald wrote:
It's still very difficult to securely process uploaded files under a different user account. Some SFTP clients set restrictive permissions on upload, and the OpenSSH implementation does not allow to bypass that.
man umask
[root@rh:/downloads]$ cat /etc/ssh/sshd_config | grep internal-sftp Subsystem sftp internal-sftp -u 006
umask doesn't apply to explicit chmod
besides that we get way too off-topic and my first reply was in context of "because ssh is giving too much access" which is a wrong anecdote: fine, the same applies for samba, ftp and any other file transfer protocol if you want 100% defined permissions you need to use inotify and handmade daemons in any case because the client can fire always a chmod of files he own
this is the proverbal security vs. convenience issue safety unfortunately isn't convenient
Corey W Sheldon Owner, 1st Class Mobile Shine 310.909.7672 www.facebook.com/1stclassmobileshine
On Mon, Mar 24, 2014 at 8:21 AM, Florian Weimer fweimer@redhat.com wrote:
On 03/24/2014 01:06 PM, Reindl Harald wrote:
Am 24.03.2014 12:57, schrieb Nicolas Mailhot:
Le Sam 22 mars 2014 01:20, Miloslav Trmač a écrit :
The RHEL documentation, apart from fully describing the abilities,
specifically describes two uses: a ftpd banner
Surprisingly, ftp is still widely used entreprise-side, because ssh is giving too much access
no, it is easy to restrict ssh to ONLY sftp and chroot and with simple bind-mounts you can completly replace ftp, doing that here in production over years with 3 simple scripts
It's still very difficult to securely process uploaded files under a different user account. Some SFTP clients set restrictive permissions on upload, and the OpenSSH implementation does not allow to bypass that.
-- Florian Weimer / Red Hat Product Security Team
-- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Le Jeu 20 mars 2014 20:44, Stephen John Smoogen a écrit :
I am giving you a standard enterprise problem.
I can confirm that thanks to the stability of the config file, tcpwrappers is widely used here.
IPtables has just started getting some adoption (after years of turf wars between firewall admin and server admins) but I'm not confident a lot of projects will really use it (unfortunately, iptables did *not* have clearly defined configuration rules, so it's a free-for-all a lot of projects do not want to mess with).
Selinux is the future that will arrive someday when someone dares making it mandatory (and accepts the inevitable fallout when enterprisey stuff like Oracle and friends start failing right and left)
I really wish there was less energy spent on what the code looks from the inside and more than providing stable easy to use user interface. You can rewrite code twenty times no one will care as long as the interface is familiar. Break configuration syntax or other interfaces, however, and all hell breaks loose.
And before someone complains of sysadmin stop energy: Microsoft core fonts (1996-era stuff) are still in the top #5 sourceforge downloads, despite being years out of date and unmaintained, and despite the boatloads of better FLOSS fonts which have been released in the past years. I'm sure they are still in Fedora install howtos.
THAT's how badly users want human interface stability, be it on the server or the desktop side.
On 03/20/2014 08:05 PM, Lennart Poettering wrote:
On Thu, 20.03.14 12:20, Stephen John Smoogen (smooge@gmail.com) wrote:
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.
Well, all mails servers as well as sshd have much better ways to do such filtering. sshd has "Match", Postfix for example has "smtpd_client_restrictions=", and so on.
I'd like to note that you can't just replace deny.hosts using Match block in sshd_config.
- using libwrap, a connection is dropped before the protocol version exchange so a client can't even check the server's identification string. While using Match block, a client and a server exchange id strings, negotiate the transport layer parameters, exchange keys and establish encrypted connection.
- in Match block, you can only change keywords related to authentication or ssh sessions
- every change in sshd_config has to be confirmed by sshd restart, while changing hosts.deny doesn't need any other action
Petr
Again, I have no doubt that some people still use tcpwrappers. But I'd argue that is clearly the excpetion, not the rule, and they'd better use something different, and that we should be creating an excellent distro, instead of a one that features horrible software...
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.
Well, it certainly makes sense to combine a firewall with let's say selinux with maybe postfix/ssh acls. Then you already have three layers of protection, of very good protection. But of all possible options tcpwrap is the absolute worst choice. And we should be able to deprecate and remove stuff from our core OS if we think it is crap.
I mean, there are two sides of the medal: sure multiple layers of protection might be a good thing, but you also make things a lot more complex with each one, and you involve more possibly exploitable code -- and tcpwrap is simply bad code, that's a fact. So you have to balance things out: is something a layer that is worth the trouble? Or does having it around make things worse? I am of the opinion that tcpwrap indeed does make things worse.
Sure, three layers of condoms probably make sex safer, but then again, if one of them is made of 10 year old half-decomposed goat intestines, then maybe the sex is a lot less fun, too...
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. ]
Well, that really sounds like a specific issue of your company... Really, I don't think the question whether the bureaucracy of some hypothetical company makes a distinction between tcwrap and firewalls has no place in the discussion whether we should support tcpwrap in our distro or not.
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.
Why? Other than your hypothetical bureaucracy, is there anything that tcpwrap can do that firewalls can't do, that really deserves to be supported? I really can't see anything... [1]
tcpd comes from a time when there weren't local firewalls available in all Unix systems, so they built something like them in userspace. But that time is long long gone, and pretty much any Linux installation I know nowadays has a firewall compiled into the kernel...
Lennart
[1] well, sure tcpwrap resolves DNS dynamically and can use that for access control, but people who bind access control to DNS really should find a different job than administrator...
Am 28.03.2014 14:39, schrieb Petr Lautrbach:
On 03/20/2014 08:05 PM, Lennart Poettering wrote:
On Thu, 20.03.14 12:20, Stephen John Smoogen (smooge@gmail.com) wrote:
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.
Well, all mails servers as well as sshd have much better ways to do such filtering. sshd has "Match", Postfix for example has "smtpd_client_restrictions=", and so on.
I'd like to note that you can't just replace deny.hosts using Match block in sshd_config.
- using libwrap, a connection is dropped before the protocol version exchange so a client can't even check the server's
identification string. While using Match block, a client and a server exchange id strings, negotiate the transport layer parameters, exchange keys and establish encrypted connection.
which is *layered* security
that is the same reason why "put the rules in iptables" is only a uneducated phrase and anybody who will put all his security in a single layer sooner or later regret that mistake
- every change in sshd_config has to be confirmed by sshd restart, while changing hosts.deny doesn't need
any other action
no - try it out!
make a fatal syntax error in "sshd_config" and in case of a remote machine make sure you don't close the last connection because you will not reach the machine again otherwise
On 03/28/2014 02:44 PM, Reindl Harald wrote:
- every change in sshd_config has to be confirmed by sshd restart, while changing hosts.deny doesn't need
any other action
no - try it out!
make a fatal syntax error in "sshd_config" and in case of a remote machine make sure you don't close the last connection because you will not reach the machine again otherwise
[14:46:53 root@malas ~ ]# /usr/sbin/sshd -T /etc/ssh/sshd_config: line 157: Bad configuration option: blbla /etc/ssh/sshd_config line 157: Directive 'blbla' is not allowed within a Match block [14:46:55 root@malas ~ ]# ssh localhost Fedora release 21 (Rawhide) root@localhost's password:
Petr
Am 28.03.2014 14:48, schrieb Petr Lautrbach:
On 03/28/2014 02:44 PM, Reindl Harald wrote:
- every change in sshd_config has to be confirmed by sshd restart, while changing hosts.deny doesn't need
any other action
no - try it out!
make a fatal syntax error in "sshd_config" and in case of a remote machine make sure you don't close the last connection because you will not reach the machine again otherwise
[14:46:53 root@malas ~ ]# /usr/sbin/sshd -T /etc/ssh/sshd_config: line 157: Bad configuration option: blbla /etc/ssh/sshd_config line 157: Directive 'blbla' is not allowed within a Match block [14:46:55 root@malas ~ ]# ssh localhost Fedora release 21 (Rawhide) root@localhost's password:
not sure which options are connection specific but there are for sure ones which do not need a restart and get effective for every new connection, i have not the time to seek and reproduce that but it's a fact from real work expierience
On Thu, 20 Mar 2014 20:05:21 +0100 Lennart Poettering mzerqung@0pointer.de wrote:
Well, all mails servers as well as sshd have much better ways to do such filtering. sshd has "Match",
The sshd's Match does not have any historic criteria (e.g. sshd does not keep a database of previous login attempts). It is not possible to import an address match from elsewhere either (where e.g. denyhosts could write it). In short, Match cannot replay fail2ban and denyhosts, as far as I can see.
I think your original idea of using firewalls was better. Someone just has to implement it. Unfortunately, I'm neck-deep in cloud storage at the moment, so I'm not volunteering.
-- Pete
On 20/03/14 20:05, Lennart Poettering wrote:
On Thu, 20.03.14 12:20, Stephen John Smoogen (smooge@gmail.com) wrote:
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.
Well, all mails servers as well as sshd have much better ways to do such filtering. sshd has "Match", Postfix for example has "smtpd_client_restrictions=", and so on.
Again, I have no doubt that some people still use tcpwrappers. But I'd argue that is clearly the excpetion, not the rule, and they'd better use something different, and that we should be creating an excellent distro, instead of a one that features horrible software...
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.
Well, it certainly makes sense to combine a firewall with let's say selinux with maybe postfix/ssh acls. Then you already have three layers of protection, of very good protection. But of all possible options tcpwrap is the absolute worst choice. And we should be able to deprecate and remove stuff from our core OS if we think it is crap.
I mean, there are two sides of the medal: sure multiple layers of protection might be a good thing, but you also make things a lot more complex with each one, and you involve more possibly exploitable code -- and tcpwrap is simply bad code, that's a fact. So you have to balance things out: is something a layer that is worth the trouble? Or does having it around make things worse? I am of the opinion that tcpwrap indeed does make things worse.
I happen to share Stephens concerns. I think tcpwrappers is a good additional security layer. And I honestly don't buy the idea that code which is 11 years old is crap by default. If it has gone 11 years, being widely used by several services (including high-profile services such as SSH), that tells me something about the quality of the *performing* code. New code is better just because it's new.
That we have a "firewall" layer which resides in the application level is a plus. Netfilter/iptables and SELinux are in kernel space, tcpwrapper is in the user-space.
Yes, more layers adds complexity. But adding more security layers usually doesn't make any setups less complicated. Managing security properly is a complicated task.
I would further like to hear *how* you mean tcpwrappers "make things worse". You just state it, you don't provide any arguments supporting it.
And comparing code and condoms is just as clever as comparing age and wisdom.
-- kind regards,
David Sommerseth
On 06/06/14 00:25, David Sommerseth wrote:
On 20/03/14 20:05, Lennart Poettering wrote:
On Thu, 20.03.14 12:20, Stephen John Smoogen (smooge@gmail.com) wrote:
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.
Well, all mails servers as well as sshd have much better ways to do such filtering. sshd has "Match", Postfix for example has "smtpd_client_restrictions=", and so on.
Again, I have no doubt that some people still use tcpwrappers. But I'd argue that is clearly the excpetion, not the rule, and they'd better use something different, and that we should be creating an excellent distro, instead of a one that features horrible software...
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.
Well, it certainly makes sense to combine a firewall with let's say selinux with maybe postfix/ssh acls. Then you already have three layers of protection, of very good protection. But of all possible options tcpwrap is the absolute worst choice. And we should be able to deprecate and remove stuff from our core OS if we think it is crap.
I mean, there are two sides of the medal: sure multiple layers of protection might be a good thing, but you also make things a lot more complex with each one, and you involve more possibly exploitable code -- and tcpwrap is simply bad code, that's a fact. So you have to balance things out: is something a layer that is worth the trouble? Or does having it around make things worse? I am of the opinion that tcpwrap indeed does make things worse.
I happen to share Stephens concerns. I think tcpwrappers is a good additional security layer. And I honestly don't buy the idea that code which is 11 years old is crap by default. If it has gone 11 years, being widely used by several services (including high-profile services such as SSH), that tells me something about the quality of the *performing* code. New code is better just because it's new.
you are *clearly* not up-to-date with regard to currently on-going flame-wars:
"heads up: tcpwrappers support going away" Damien Miller djm at mindrot.org Tue Apr 22 17:33:59 EST 2014
http://lists.mindrot.org/pipermail/openssh-unix-dev/2014-April/032497.html
* Stephen John Smoogen:
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.]
I believe DenyHosts is unmaintained as well:
https://bugzilla.redhat.com/show_bug.cgi?id=1045983
At the enterprise level firewalls can come under a different set of change control rules than something like tcpwrappers which is considered application level.
I think it's difficult to generalize in this area. There is no inherent reason why an iptables-based local packet filter has to follow the same sign-off rules as a device on the forwarding path.
From my POV, it is kind of neat that you can grant access to *.enyo.de
and deny every thing else. This is quite helpful against scanners and worms, and programs like OpenSSH rely on tcpwrappers to implement this. It's not clear to me if this has to happen at the systemd level, though.
On Thu, 20.03.14 20:06, Florian Weimer (fw@deneb.enyo.de) wrote:
- Stephen John Smoogen:
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.]
I believe DenyHosts is unmaintained as well:
https://bugzilla.redhat.com/show_bug.cgi?id=1045983
At the enterprise level firewalls can come under a different set of change control rules than something like tcpwrappers which is considered application level.
I think it's difficult to generalize in this area. There is no inherent reason why an iptables-based local packet filter has to follow the same sign-off rules as a device on the forwarding path.
From my POV, it is kind of neat that you can grant access to *.enyo.de and deny every thing else.
Binding access control to DNS sounds insecure like hell..
This is quite helpful against scanners and worms, and programs like OpenSSH rely on tcpwrappers to implement this. It's not clear to me if this has to happen at the systemd level, though.
OpenSSH can do this on its own without involving tcpwrap:
https://raymii.org/s/tutorials/Limit_access_to_openssh_features_with_the_Mat...
It sounds like a much better choice to stick to that instead of involving tcpwrap, and we should push our users to understand that...
Lennart
* Lennart Poettering:
From my POV, it is kind of neat that you can grant access to *.enyo.de and deny every thing else.
Binding access control to DNS sounds insecure like hell..
Additional restrictions are fine, for this purpose:
This is quite helpful against scanners and worms,
(And with DNSSEC, it wouldn't be so insecure anymore, you don't even need a secured reverse tree before it can be effective.)
OpenSSH can do this on its own without involving tcpwrap:
https://raymii.org/s/tutorials/Limit_access_to_openssh_features_with_the_Mat...
It sounds like a much better choice to stick to that instead of involving tcpwrap, and we should push our users to understand that...
The nice thing about tcpwrappers is that it runs extremely early, typically before any application code is exposed. Something in the guts of OpenSSH really isn't comparable. It's not immediately obvious how you'd block logins altogether.
On Thu, 20.03.14 20:36, Florian Weimer (fw@deneb.enyo.de) wrote:
OpenSSH can do this on its own without involving tcpwrap:
https://raymii.org/s/tutorials/Limit_access_to_openssh_features_with_the_Mat...
It sounds like a much better choice to stick to that instead of involving tcpwrap, and we should push our users to understand that...
The nice thing about tcpwrappers is that it runs extremely early, typically before any application code is exposed. Something in the guts of OpenSSH really isn't comparable. It's not immediately obvious how you'd block logins altogether.
Well, the thing though is that the OpenSSH code is not as bad as tcpwrap. I'd much rather have OpenSSH handle this than tcpwrap...
And if it's not "immediately obvious", then we can certainly fix that with adding more docs, or explaining this in the release notes?
Lennart
On Thu, Mar 20, 2014 at 08:06:26PM +0100, Florian Weimer wrote:
I believe DenyHosts is unmaintained as well:
fail2ban is maintained, does basically the same thing, can use iptables and optionally firewalld, and can watch the systemd journal. Maybe that could go in the release notes.
I think in general that part of the reason tcp_wrappers has rotted is that interfaces to packet filtering tools have gotten better and easier over the past two decades.
I'm basically in favor of this, with a big star put by Stephen Smoogen's concern about enterprise defense-in-depth policies. But just so no one is surprised if I say this later, unless there is overwhelming feedback that it's time for it to go now, I think it's reasonable to declare it deprecated for F21, with release notes, warnings in hosts.allow and hosts.deny, updates in the documentation (which current recommends using both in conjunction) http://docs.fedoraproject.org/en-US/Fedora/19/html/Security_Guide/sect-Secur... and so on. Then if that goes smoothly and gets positive (or, zero) user feedback, we can remove it for F22.
On Thu, Mar 20, 2014 at 03:50:07PM -0400, Matthew Miller wrote:
it's time for it to go now, I think it's reasonable to declare it deprecated for F21, with release notes, warnings in hosts.allow and hosts.deny, updates
And by "declare", I mean "decide collectively to declare" -- sorry if that was unclear.
On Thu, Mar 20, 2014 at 1:34 PM, Lennart Poettering mzerqung@0pointer.dewrote:
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
As Stephen points out, they are used. Does systemd+xinetd match their functionality?
cheers,
m
On Thu, 20.03.14 14:31, Martin Langhoff (martin.langhoff@gmail.com) wrote:
On Thu, Mar 20, 2014 at 1:34 PM, Lennart Poettering mzerqung@0pointer.dewrote:
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
As Stephen points out, they are used. Does systemd+xinetd match their functionality?
No. systemd is not a firewall. It currently supports libwrap checks for socket activated services. And I'd really like to get rid of that...
I have no doubt that some people use them, however I am also pretty sure that they are massively awful, and not worth the trouble, and that I'd prefer not to see this crap in the default install. However, since the library is currently hooked into a lot of services (starting with systemd itself) I currently cannot do "rpm -e".
I mean, I really don't mind that tcpd/tcpwrap stays in the archives, if people want to make use of that. I am simply proposing to not link agains them anymore for everything that is in the default system.
Lennart
Hi,
On 03/20/2014 07:45 PM, Lennart Poettering wrote:
On Thu, 20.03.14 14:31, Martin Langhoff (martin.langhoff@gmail.com) wrote:
On Thu, Mar 20, 2014 at 1:34 PM, Lennart Poettering mzerqung@0pointer.dewrote:
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
As Stephen points out, they are used. Does systemd+xinetd match their functionality?
No. systemd is not a firewall. It currently supports libwrap checks for socket activated services. And I'd really like to get rid of that...
I have no doubt that some people use them, however I am also pretty sure that they are massively awful, and not worth the trouble, and that I'd prefer not to see this crap in the default install. However, since the library is currently hooked into a lot of services (starting with systemd itself) I currently cannot do "rpm -e".
I mean, I really don't mind that tcpd/tcpwrap stays in the archives, if people want to make use of that. I am simply proposing to not link agains them anymore for everything that is in the default system.
So as an innocent bystander who happens to be reading along this thread, I see 2 sides to the story here:
Lennart says: 1) It is horrible code 2) It really really is horrible horrible code 3) And there are other ways to achieve the same goal, so lets kill it
Others say: 1) There may be other ways but non so easily central managed with with a unified syntax for all services
The argument which the others are making actually sounds a lot like a lot of the arguments in favor of systemd (wrt standardizing, etc.).
And I'm getting the feeling that Lennart is not as much opposed to the functionality of tcp-wrappers, as that he *really* hates the code.
So maybe a solution would be to write a libwrap2 instead ?
So offer something with equivalent functionality (and config file syntax compatibility), with a nice modern clean API and then systemd and others can be moved over to that 1 by 1, and once we've no more users left we can kill of the old beast ?
Note I've nothing to do with anything in this discussion, but I just noticed a certain trend in it and I hope the above may lead to a more fruitful discussion.
Regards,
Hans
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 03/20/2014 01:55 PM, Hans de Goede wrote:
Hi,
On 03/20/2014 07:45 PM, Lennart Poettering wrote:
On Thu, 20.03.14 14:31, Martin Langhoff (martin.langhoff@gmail.com) wrote:
On Thu, Mar 20, 2014 at 1:34 PM, Lennart Poettering mzerqung@0pointer.dewrote:
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
As Stephen points out, they are used. Does systemd+xinetd match their functionality?
No. systemd is not a firewall. It currently supports libwrap checks for socket activated services. And I'd really like to get rid of that...
I have no doubt that some people use them, however I am also pretty sure that they are massively awful, and not worth the trouble, and that I'd prefer not to see this crap in the default install. However, since the library is currently hooked into a lot of services (starting with systemd itself) I currently cannot do "rpm -e".
I mean, I really don't mind that tcpd/tcpwrap stays in the archives, if people want to make use of that. I am simply proposing to not link agains them anymore for everything that is in the default system.
So as an innocent bystander who happens to be reading along this thread, I see 2 sides to the story here:
Lennart says: 1) It is horrible code 2) It really really is horrible horrible code 3) And there are other ways to achieve the same goal, so lets kill it
Others say: 1) There may be other ways but non so easily central managed with with a unified syntax for all services
The argument which the others are making actually sounds a lot like a lot of the arguments in favor of systemd (wrt standardizing, etc.).
And I'm getting the feeling that Lennart is not as much opposed to the functionality of tcp-wrappers, as that he *really* hates the code.
So maybe a solution would be to write a libwrap2 instead ?
So offer something with equivalent functionality (and config file syntax compatibility), with a nice modern clean API and then systemd and others can be moved over to that 1 by 1, and once we've no more users left we can kill of the old beast ?
Note I've nothing to do with anything in this discussion, but I just noticed a certain trend in it and I hope the above may lead to a more fruitful discussion.
Regards,
Hans
Hans, Now that is just too entirely rational ;).
This sounds like a wonderful solution, but someone has to be willing to write the thing.
- -Erinn
On 20 March 2014 13:55, Hans de Goede hdegoede@redhat.com wrote:
Hi,
On 03/20/2014 07:45 PM, Lennart Poettering wrote:
On Thu, 20.03.14 14:31, Martin Langhoff (martin.langhoff@gmail.com)
wrote:
On Thu, Mar 20, 2014 at 1:34 PM, Lennart Poettering <
mzerqung@0pointer.de>wrote:
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
As Stephen points out, they are used. Does systemd+xinetd match their functionality?
No. systemd is not a firewall. It currently supports libwrap checks for socket activated services. And I'd really like to get rid of that...
I have no doubt that some people use them, however I am also pretty sure that they are massively awful, and not worth the trouble, and that I'd prefer not to see this crap in the default install. However, since the library is currently hooked into a lot of services (starting with systemd itself) I currently cannot do "rpm -e".
I mean, I really don't mind that tcpd/tcpwrap stays in the archives, if people want to make use of that. I am simply proposing to not link agains them anymore for everything that is in the default system.
So as an innocent bystander who happens to be reading along this thread, I see 2 sides to the story here:
Lennart says:
- It is horrible code
- It really really is horrible horrible code
- And there are other ways to achieve the same goal, so lets kill it
Others say:
- There may be other ways but non so easily central managed with with
a unified syntax for all services
The argument which the others are making actually sounds a lot like a lot of the arguments in favor of systemd (wrt standardizing, etc.).
And I'm getting the feeling that Lennart is not as much opposed to the functionality of tcp-wrappers, as that he *really* hates the code.
So maybe a solution would be to write a libwrap2 instead ?
So offer something with equivalent functionality (and config file syntax compatibility), with a nice modern clean API and then systemd and others can be moved over to that 1 by 1, and once we've no more users left we can kill of the old beast ?
Note I've nothing to do with anything in this discussion, but I just noticed a certain trend in it and I hope the above may lead to a more fruitful discussion.
Yes I agree Hans. I think this is the rational and correct course. I also realize that it isn't Lennart's job to do so even if I wish he would.
2014-03-20 20:55 GMT+01:00 Hans de Goede hdegoede@redhat.com:
Lennart says:
- It is horrible code
- It really really is horrible horrible code
- And there are other ways to achieve the same goal, so lets kill it
Others say:
- There may be other ways but non so easily central managed with with
a unified syntax for all services
Yes. It's notable that almost every widely-used network server that doesn't use tcp_wrappers has needed to add a very similar set of options; so we shouldn't expect that tcp_wrappers were removed users would stop using or asking for that kind of functionality.
Centralizing the language, semantics and implementation is clearly a better UI and better design. Not only for the common case of "the same option has a different name in the other daemon", but also for the corner cases like error behavior where various independent implementations differ in surprising ways. Such surprises are great starting points for attackers looking to bypass policy.
From the users' POV, moving from tcp_wrappers to per-daemon configuration
is a clear step backwards. If the implementers' POV differs, that's a reason to change the implementation, not to discard the feature. Mirek
On Thu, 20.03.14 20:55, Hans de Goede (hdegoede@redhat.com) wrote:
I mean, I really don't mind that tcpd/tcpwrap stays in the archives, if people want to make use of that. I am simply proposing to not link agains them anymore for everything that is in the default system.
So as an innocent bystander who happens to be reading along this thread, I see 2 sides to the story here:
Lennart says:
- It is horrible code
- It really really is horrible horrible code
- And there are other ways to achieve the same goal, so lets kill it
I am not just saying "other ways", but *better* ways.
I am also saying that keeping this around makes the OS unnecessarily more complex.
Others say:
- There may be other ways but non so easily central managed with with
a unified syntax for all services
The argument which the others are making actually sounds a lot like a lot of the arguments in favor of systemd (wrt standardizing, etc.).
Well the difference here is pretty much that there was no pre-existing standardization effort for the areas that systemd covered really.
However, there's a technically much better, established, better understood alternative to tcpwrappers, and that's a firewall.
And I'm getting the feeling that Lennart is not as much opposed to the functionality of tcp-wrappers, as that he *really* hates the code.
I am actually against this as seperate functionality too. Go high-level with service-specific filtering. Or go low-level with a firewall. Don't waste your time with tcpwrap...
So maybe a solution would be to write a libwrap2 instead ?
Oh, please no. We already have firewalls for this.
If you want to write new code: I think it would be a lot nicer to simply write a converter for hosts.allow and hosts.deny into iptables rules, plus some warnings if DNS and IDENT matches are used.
So offer something with equivalent functionality (and config file syntax compatibility), with a nice modern clean API and then systemd and others can be moved over to that 1 by 1, and once we've no more users left we can kill of the old beast ?
Nope. In systemd we already support one subsystem for filtering just fine, it's called a firewall. I am looking for a way to simplify things, and remove unnecessary redundancies. And just rewriting something that is redundant and a bad idea in the first place, certainly doesn't help there...
Lennart
Am 21.03.2014 01:17, schrieb Lennart Poettering:
On Thu, 20.03.14 20:55, Hans de Goede (hdegoede@redhat.com) wrote:
So offer something with equivalent functionality (and config file syntax compatibility), with a nice modern clean API and then systemd and others can be moved over to that 1 by 1, and once we've no more users left we can kill of the old beast ?
Nope. In systemd we already support one subsystem for filtering just fine, it's called a firewall. I am looking for a way to simplify things, and remove unnecessary redundancies. And just rewriting something that is redundant and a bad idea in the first place, certainly doesn't help there...
http://en.wikipedia.org/wiki/Defence_in_depth#Non-military_examples
* Lennart Poettering:
So offer something with equivalent functionality (and config file syntax compatibility), with a nice modern clean API and then systemd and others can be moved over to that 1 by 1, and once we've no more users left we can kill of the old beast ?
Nope. In systemd we already support one subsystem for filtering just fine, it's called a firewall.
Does this subsystem support DNS-based rules?
Am 21.03.2014 20:02, schrieb Florian Weimer:
- Lennart Poettering:
So offer something with equivalent functionality (and config file syntax compatibility), with a nice modern clean API and then systemd and others can be moved over to that 1 by 1, and once we've no more users left we can kill of the old beast ?
Nope. In systemd we already support one subsystem for filtering just fine, it's called a firewall.
Does this subsystem support DNS-based rules?
and even if it does you do *not* want dns-resolution based on packets instead connections - guess how many users would make the mistake resulting in a selfDOS
On Fri, 21.03.14 20:02, Florian Weimer (fw@deneb.enyo.de) wrote:
- Lennart Poettering:
So offer something with equivalent functionality (and config file syntax compatibility), with a nice modern clean API and then systemd and others can be moved over to that 1 by 1, and once we've no more users left we can kill of the old beast ?
Nope. In systemd we already support one subsystem for filtering just fine, it's called a firewall.
Does this subsystem support DNS-based rules?
No, firewalls don't do DNS-based filtering, since it's a security nightmare.
Lennart
On Sat, Mar 22, 2014 at 02:59:20AM +0100, Lennart Poettering wrote:
No, firewalls don't do DNS-based filtering, since it's a security nightmare.
Lennart, this isn't true as a general statement. Both Juniper and Cisco firewalls support FQDN-based access rules. Looks like Palo Alto Networks too although I have not used those.
Of course, this doesn't demonstrate that it's a good idea, just that it is actually something people use and which there is demand for. If anything, though, I think this makes me less concerned about deprecating tcp_wrappers since people can find equivalent functionality elsewhere if they want it. (And, I think you could do it on Linux with dnsmasq's ipset functionality if you really wanted to.)
Hi,
So maybe a solution would be to write a libwrap2 instead ?
Don't think this is the solution. Part of the problem is that some of the functionality is just obsolete in todays world. Trusting IDENT and DNS for access control maybe made sense in the 90ies. It certainly doesn't today, and IMO lennart is correct in classifying this as "security theater".
So offer something with equivalent functionality (and config file syntax compatibility), with a nice modern clean API and then systemd and others can be moved over to that 1 by 1, and once we've no more users left we can kill of the old beast ?
I'd say moving the functionality which still makes sense (ip range based checks) to the firewall is more useful. Guess it shouldn't be that hard to write a utility translating /etc/hosts.{allow,deny} into iptables rules, or add support for that to firewalld.
Does tcpwrap support ipv6 btw?
cheers, Gerd
On Thu, 2014-03-20 at 20:55 +0100, Hans de Goede wrote:
So offer something with equivalent functionality (and config file syntax compatibility), with a nice modern clean API and then systemd and others can be moved over to that 1 by 1, and once we've no more users left we can kill of the old beast ?
+1 I use tcp-wrappers, if only for fail-over. Layered defense i suppose.
On Thursday 20 March 2014 19:45:32 Lennart Poettering wrote:
No. systemd is not a firewall. It currently supports libwrap checks for socket activated services. And I'd really like to get rid of that...
Confession: I've never bothered looking in tcpwrappers code/api, so I'll take your assessment that this code should be thrown away...
However, the functionality *at the service level* has its value, as a complement to firewall rules which are global by nature.
Let's look at familiar NON-tcpwrappers examples: * Every sane network service allows you to bind to specific interfaces although you could protect them via firewall rules.
It's not *only* security, but also flexibility (e.g: running several instances on several [physical or virtual] network interfaces).
Sometimes it's just extra *safety* (e.g: you don't want an internal DHCP server to answer hosts on the corporate network by mistake).
* You mentioned yourself the sshd "Match" keyword. Again, it's not just "security" per-se, but the softer ability to control a network resource *at the service level*.
* xinetd also support some socket control options (besides optional tcpwrappers integration). E.g: "per_source" or "cps" directives.
* Last, a somewhat theoretical example. User-level services. (e.g: screen sharing of personal desktop like "krfb"). The non-root user may not have global control on the host and firewall but may want to set limits who can bother him/her.
(it's theoretical simply because current implementations doesn't give the user any such control ;-)
So is there any chance to have similar functionality? * IMO, exact feature/syntax parity with tcpwrappers isn't important at all.
* However, *some* optional socket control/limits in <service>.socket file would go a long way.
* If this happens to be implemented in a small library with sane API, it may even contribute to the direct replacement of tcpwrappers in other network services that need similar features...
Thanks,
On Thu, Mar 20, 2014 at 10:48:53PM +0200, Oron Peled wrote:
On Thursday 20 March 2014 19:45:32 Lennart Poettering wrote:
No. systemd is not a firewall. It currently supports libwrap checks for socket activated services. And I'd really like to get rid of that...
Confession: I've never bothered looking in tcpwrappers code/api, so I'll take your assessment that this code should be thrown away...
I did just look at the code, and it doesn't look too bad to me. I'd be interested hearing about specific problems with it.
http://gitweb.dragonflybsd.org/dragonfly.git/tree?f=contrib/tcp_wrappers
On the other hand, I'll note that Arch dropped tcp_wrappers support in 2011.
Rich.
On Mar 20, 2014, at 12:31 PM, Martin Langhoff martin.langhoff@gmail.com wrote:
On Thu, Mar 20, 2014 at 1:34 PM, Lennart Poettering mzerqung@0pointer.de wrote: 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
As Stephen points out, they are used. Does systemd+xinetd match their functionality?
cheers,
m
I have to say that there are certain out-of-the-box services that it’s nice to be able to block access at the application-level, which would be hard to do at the transport or network layer.
RPC-based services being the most obvious, but also things like FTP or TFTP or VNC or X that don’t always have port numbers that are easily expressed… Then there’s filtering on DNS hostname suffixes, etc… NIS+ membership...
I’m fine with seeing systemd being decoupled from them, but I’d like to see legacy services continue to work with tcpwrappers (libwrap).
-Philip
On Thu, Mar 20, 2014 at 06:34:22PM +0100, Lennart Poettering wrote:
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
I talked to some of the RHEL planning people, and they're okay with marking it deprecated in RHEL7. That allays some of my concerns about downstream enterprise needs -- although there was also the comment that the libwrap2 approach would be a good one.
I'm also collecting some feedback from CentOS users. I'll wait to report on that for a little bit, but I think in general the majority response is okay with it, with a significantly vocal "why change things that work?" contingent, and also the more practical concerns that a) tcp_wrappers is cross-platform for mixed Linux/Unix shops where iptables is not, and b) CIS (Center for Internet Security) benchmarks (taken seriously in many enterprises) recommend both TCP wrappers and host-based packet filtering, noting "TCP Wrappers and Host-Based Firewalls are presented together as they are similar and complementary in functionality."
Those two concerns do give me some pause; it might be nice to at least discuss with CIS whether the benchmark should be updated. And the cross-compatibility concern argues for either the libwrap2 idea or the compatible firewall-rule-generator concept.
On 03/21/2014 02:05 PM, Matthew Miller wrote:
On Thu, Mar 20, 2014 at 06:34:22PM +0100, Lennart Poettering wrote:
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
I talked to some of the RHEL planning people, and they're okay with marking it deprecated in RHEL7. That allays some of my concerns about downstream enterprise needs -- although there was also the comment that the libwrap2 approach would be a good one.
I'm also collecting some feedback from CentOS users. I'll wait to report on that for a little bit, but I think in general the majority response is okay with it, with a significantly vocal "why change things that work?"
In other words you are telling us that now to get something implemented or removed in Fedora we have to not only deal with our usual politics and bureaucracy but also all the downstream distribution to us as well...
JBG
On Fri, Mar 21, 2014 at 6:16 PM, "Jóhann B. Guðmundsson" <johannbg@gmail.com
wrote:
In other words you are telling us that now to get something implemented or removed in Fedora we have to not only deal with our usual politics and bureaucracy but also all the downstream distribution to us as well...
One way to avoid those pesky details is to not have users... :-)
m
On 03/21/2014 10:30 PM, Martin Langhoff wrote:
On Fri, Mar 21, 2014 at 6:16 PM, "Jóhann B. Guðmundsson" <johannbg@gmail.com mailto:johannbg@gmail.com> wrote:
In other words you are telling us that now to get something implemented or removed in Fedora we have to not only deal with our usual politics and bureaucracy but also all the downstream distribution to us as well...
One way to avoid those pesky details is to not have users... :-)
One way to prevent advancement and innovation within Fedora is precisely what's taking place here.
Three layers to get things done...
JBG
Am 21.03.2014 23:31, schrieb Jóhann B. Guðmundsson:
On 03/21/2014 10:30 PM, Martin Langhoff wrote:
On Fri, Mar 21, 2014 at 6:16 PM, "Jóhann B. Guðmundsson" <johannbg@gmail.com mailto:johannbg@gmail.com> wrote:
In other words you are telling us that now to get something implemented or removed in Fedora we have to not only deal with our usual politics and bureaucracy but also all the downstream distribution to us as well...
One way to avoid those pesky details is to not have users... :-)
One way to prevent advancement and innovation within Fedora is precisely what's taking place here.
Three layers to get things done...
you call it "innovation"
others call it bad names to break every day compatibility and force anybody to follow changes nobobody asked for because only if changes have a great impact to anybody they are recognized
the whole environment moves in circles with less to zero gain the last past years but hey you are cool if you change things
Am 21.03.2014 23:16, schrieb Jóhann B. Guðmundsson:
On 03/21/2014 02:05 PM, Matthew Miller wrote:
On Thu, Mar 20, 2014 at 06:34:22PM +0100, Lennart Poettering wrote:
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
I talked to some of the RHEL planning people, and they're okay with marking it deprecated in RHEL7. That allays some of my concerns about downstream enterprise needs -- although there was also the comment that the libwrap2 approach would be a good one.
I'm also collecting some feedback from CentOS users. I'll wait to report on that for a little bit, but I think in general the majority response is okay with it, with a significantly vocal "why change things that work?"
In other words you are telling us that now to get something implemented or removed in Fedora we have to not only deal with our usual politics and bureaucracy but also all the downstream distribution to us as well...
no, in other words he told you that whe world is not turning around a few people deperecating anything which does not get a update for the sake of a update and what some people calling "legacy" might be things not needing updates because they just works and update and replace/drop for the sake of a change does not make things better for no good reason
the author of tcpwrapper is Wietse Venema, the perosn who created and maintains postfix - frankly if only 1% of the software out there would provide his stability and backwards compatibility a lot of peole could do better things with their time than creat day for day in case of deprecations and incompatible replacemnets
most of the replacements in the last few years could have been becakward compatible if the developers would not be too lazy to care about
On 03/21/2014 10:35 PM, Reindl Harald wrote:
the author of tcpwrapper is Wietse Venema,
You do realize when he wrote this and what he was trying to overcome at that time so I have to ask have you spoken to him about how useful he thinks his creation is today and why he stopped maintaining it?
If not I suggest you do and hear what he thinks and says about it...
JBG
Am 21.03.2014 23:37, schrieb Jóhann B. Guðmundsson:
On 03/21/2014 10:35 PM, Reindl Harald wrote:
the author of tcpwrapper is Wietse Venema,
You do realize when he wrote this and what he was trying to overcome at that time so I have to ask have you spoken to him about how useful he thinks his creation is today and why he stopped maintaining it?
If not I suggest you do and hear what he thinks and says about it...
let hear
most things deprecated the past years are deprecated because they don't receive a upstrea update every weak and people depcrate them doing so because they can't imagine that things just work
if you believe it or not: there exists code which don't neeed updates and reweites all te time because it just works and given the amount of bugs in systemd Fedora 20/Rawhide, well, better there would have been no improvement after Fedora 19
does this care upstream: no it does not
but hey, propose other peoples code to be deprecatd is so much easier
On Fri, 21.03.14 23:46, Reindl Harald (h.reindl@thelounge.net) wrote:
if you believe it or not: there exists code which don't neeed updates and reweites all te time because it just works and given
You do realize that if software engineering has shown something then yes, software development is never finished, it's a process. You do need maintains for such things.
Lennart
2014-03-22 3:07 GMT+01:00 Lennart Poettering mzerqung@0pointer.de:
On Fri, 21.03.14 23:46, Reindl Harald (h.reindl@thelounge.net) wrote:
if you believe it or not: there exists code which don't neeed updates and reweites all te time because it just works and given
You do realize that if software engineering has shown something then yes, software development is never finished, it's a process. You do need maintains for such things.
Fedora does have a maintainer for the package, AFAICT sufficiently active. Mirek
On Fri, Mar 21, 2014 at 8:07 PM, Lennart Poettering mzerqung@0pointer.dewrote:
You do realize that if software engineering has shown something then yes, software development is never finished, it's a process. You do need maintains for such things.
The software in my microwave oven, coffee maker, thermostat, DVD player, stereo receiver, and many processors in my car (including engine control, antilock brakes, and many others) is quite definitely finished. That's not to say that there aren't any bugs, but the vendors aren't sending me any updated versions. That's an existence proof that software *can* be "good enough" and not need updates. Granted, most software is not "good enough", but the lack of updates to a piece of software is not sufficient to establish a priori that the software should be discarded.
Am 22.03.2014 03:07, schrieb Lennart Poettering:
On Fri, 21.03.14 23:46, Reindl Harald (h.reindl@thelounge.net) wrote:
if you believe it or not: there exists code which don't neeed updates and reweites all te time because it just works and given
You do realize that if software engineering has shown something then yes, software development is never finished, it's a process. You do need maintains for such things
i do not need maintains for things just working you do because it's your passion to replace, change and deprecate
many others and i need working systems to do my work on them
On Fri, 21.03.14 23:35, Reindl Harald (h.reindl@thelounge.net) wrote:
In other words you are telling us that now to get something implemented or removed in Fedora we have to not only deal with our usual politics and bureaucracy but also all the downstream distribution to us as well...
no, in other words he told you that whe world is not turning around a few people deperecating anything which does not get a update for the sake of a update and what some people calling "legacy" might be things not needing updates because they just works and update and replace/drop for the sake of a change does not make things better for no good reason
the author of tcpwrapper is Wietse Venema, the perosn who created and maintains postfix - frankly if only 1% of the software out
So, you do realise that the same Wietse Venema who wrote and then stopped maintaining tcpwrappers is the one who didn't add *any* tcpwrappers support to Postfix? To this day Postfix doesn't do tcpwrappers. Probably for a good reason, don't you think?
most of the replacements in the last few years could have been becakward compatible if the developers would not be too lazy to care about
Wietse is such a lazy person that he didn't had hosts.allow/.deny compatibility support to Postfix, isn't he?
Lennart
Am 22.03.2014 03:05, schrieb Lennart Poettering:
On Fri, 21.03.14 23:35, Reindl Harald (h.reindl@thelounge.net) wrote:
In other words you are telling us that now to get something implemented or removed in Fedora we have to not only deal with our usual politics and bureaucracy but also all the downstream distribution to us as well...
no, in other words he told you that whe world is not turning around a few people deperecating anything which does not get a update for the sake of a update and what some people calling "legacy" might be things not needing updates because they just works and update and replace/drop for the sake of a change does not make things better for no good reason
the author of tcpwrapper is Wietse Venema, the perosn who created and maintains postfix - frankly if only 1% of the software out
So, you do realise that the same Wietse Venema who wrote and then stopped maintaining tcpwrappers is the one who didn't add *any* tcpwrappers support to Postfix? To this day Postfix doesn't do tcpwrappers. Probably for a good reason, don't you think?
until you managed the same stability of interfaces for a couple of years like postfix don't strip quotes
most of the replacements in the last few years could have been becakward compatible if the developers would not be too lazy to care about
Wietse is such a lazy person that he didn't had hosts.allow/.deny compatibility support to Postfix, isn't he?
ask him why
On Thu, 20.03.14 18:34, Lennart Poettering (mzerqung@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.
I have decided now to drop all support for tcpwrap from systemd, for the next release. For those who believe that tcpd is really a good idea (yuck!) not much is lost though, they can just plug in tcpd into systemd, the way they did it with good old inetd, too, hence we are not taking anything away there, we are pretty much compatible with what inetd supported there (or actually: didn't support there).
I am not going to file a feature for Fedora, to remove support for it entirely across the whole distro. I still think dropping it is the right thing to do, but I don't think it's a good use of my own time, to fight this through... I'd be happy though if somebody else would pick this up. Looking at the current FESCO members I am not entirely sure though whether a proposal to disable libwrap would have a chance in the current cycle though. (also, M. Miller kinda supported the proposal, which as history tells us means he probably is _not_ going to vote for it in the end...)
It's a pity though that nobody in Fedora is actively working on getting rid of legacy cruft. I really wished we had some people who oversee deprecating things more proactively, figure out how to deprecate things, write stub code to provide smooth transitions, write release notes and so on. Being at the bleeding edge of things also means deciding that some things really should go, from time to time... Besides deprecating old cruft like libwrap, this would also mean removing all the old crap from comps "standard" that we still install by default (894110)...
Lennart
On 24 March 2014 12:18, Lennart Poettering mzerqung@0pointer.de wrote:
It's a pity though that nobody in Fedora is actively working on getting rid of legacy cruft. I really wished we had some people who oversee deprecating things more proactively, figure out how to deprecate things, write stub code to provide smooth transitions, write release notes and so on. Being at the bleeding edge of things also means deciding that some things really should go, from time to time... Besides deprecating old cruft like libwrap, this would also mean removing all the old crap from comps "standard" that we still install by default (894110)...
Old cruft is in the OS because for some set of people it is useful, and it is very hard to design around stuff people think should be there because it was there before. The only way to get around that is to build something completely new with a different 'brand' which does not have expectations from people already there. I think you would have a better chance starting from a ground zero and putting new wine in a new winesack versus trying to put it in an old one and then wondering why it keeps bursting.
On 03/24/2014 06:50 PM, Stephen John Smoogen wrote:
On 24 March 2014 12:18, Lennart Poettering <mzerqung@0pointer.de mailto:mzerqung@0pointer.de> wrote:
It's a pity though that nobody in Fedora is actively working on getting rid of legacy cruft. I really wished we had some people who oversee deprecating things more proactively, figure out how to deprecate things, write stub code to provide smooth transitions, write release notes and so on. Being at the bleeding edge of things also means deciding that some things really should go, from time to time... Besides deprecating old cruft like libwrap, this would also mean removing all the old crap from comps "standard" that we still install by default (894110)...
Old cruft is in the OS because for some set of people it is useful, and it is very hard to design around stuff people think should be there because it was there before. The only way to get around that is to build something completely new with a different 'brand' which does not have expectations from people already there. I think you would have a better chance starting from a ground zero and putting new wine in a new winesack versus trying to put it in an old one and then wondering why it keeps bursting.
It has been tried and tested and the people that suggested that ( me in particular in relation with the serverWG ) got burned on the stakes, accused wanting to "fork" Fedora for suggesting just that as in cleaning and implementing the output from that work in a separated repository's under a new brand until we were confident enough to with that effort and drop replace Fedora as we know it with that effort.
The fact is there is a lot of legacy cruff we should be removing as well as doing other necessary cleanups to make Fedora agile again for the upcoming changes in the IT industry landscape.
But certain people seem to rather want to drown Fedora in bureaucracy and vague future proposals and working groups instead of doing what needs to be done.
JBG
Am 24.03.2014 20:27, schrieb Jóhann B. Guðmundsson:
But certain people seem to rather want to drown Fedora in bureaucracy and vague future proposals and working groups instead of doing what needs to be done.
no, certain people want to do something *useful* with their sytems and precious time and not remove things and adopt changes with no good reason
if you want to do worthful things go ahead as your QA job and clean systemd especially the first one of the following list, they all hurt over months and #1072368 comes back with the last systemd releases in Rawhide
https://bugzilla.redhat.com/show_bug.cgi?id=1072368 https://bugzilla.redhat.com/show_bug.cgi?id=1010572 https://bugzilla.redhat.com/show_bug.cgi?id=626477 https://bugzilla.redhat.com/show_bug.cgi?id=1047148 https://bugzilla.redhat.com/show_bug.cgi?id=1024379
On Mon, 24.03.14 20:59, Reindl Harald (h.reindl@thelounge.net) wrote:
Am 24.03.2014 20:27, schrieb Jóhann B. Guðmundsson:
But certain people seem to rather want to drown Fedora in bureaucracy and vague future proposals and working groups instead of doing what needs to be done.
no, certain people want to do something *useful* with their sytems and precious time and not remove things and adopt changes with no good reason
if you want to do worthful things go ahead as your QA job and clean systemd especially the first one of the following list, they all hurt over months and #1072368 comes back with the last systemd releases in Rawhide
You know, Harald, with your constant complaining you are just ensuring that people will ignore whatever you say. For example, when I see a bug reported by you I put it at the very end of my TODO list, because I really don't want to deal with the constant complaints we are getting from you.
You know, you are not dumb, and the stuff you post is often quite relevant to our work, but as long as you post this stuff the way you do the only thing you will achieve quickly is that we'll ignore what you say, and that you get moderated again on mailing lists like systemd-devel like you already got twice. That is a loss, since there are things in what you say that I find quite relevant. But jeesus, it's so frickin annoying to deal with you and your writings, you know that?
https://bugzilla.redhat.com/show_bug.cgi?id=1072368 https://bugzilla.redhat.com/show_bug.cgi?id=1010572 https://bugzilla.redhat.com/show_bug.cgi?id=626477 https://bugzilla.redhat.com/show_bug.cgi?id=1047148 https://bugzilla.redhat.com/show_bug.cgi?id=1024379
Quite frankly, these all are fixed upstream, or relatively harmless things like where you'd prefer us to generate less log messages. Making such a fuss about these things is way over the top. Not a single one of these you posted is about actual functionality bugs not getting fixed upstream.
Please try to understand that things like this don't get the highest priority on our TODO list. Also, you don't have the privilige of being entitled to get your own private bugs fixed immeidately, really. Yes, it would be nice if we fix them, but open source is really not just about you demanding things and we giving it to you. It's a two way street, so instead of all the negative energy you spend bitching about things, how about actually doing something really constructive, figuring out a patch or so, for the relevant things, and submitting that?
Lennart
Am 24.03.2014 21:32, schrieb Lennart Poettering:
On Mon, 24.03.14 20:59, Reindl Harald (h.reindl@thelounge.net) wrote:
Am 24.03.2014 20:27, schrieb Jóhann B. Guðmundsson:
But certain people seem to rather want to drown Fedora in bureaucracy and vague future proposals and working groups instead of doing what needs to be done.
no, certain people want to do something *useful* with their sytems and precious time and not remove things and adopt changes with no good reason
if you want to do worthful things go ahead as your QA job and clean systemd especially the first one of the following list, they all hurt over months and #1072368 comes back with the last systemd releases in Rawhide
You know, Harald, with your constant complaining you are just ensuring that people will ignore whatever you say
no more ignore is hardly possible systemd in F19 was perfect systemd in F20 is horrible from the view of a sysadmin
For example, when I see a bug reported by you I put it at the very end of my TODO list, because I really don't want to deal with the constant complaints we are getting from you.
if you would do your job better i would not have to complain
You know, you are not dumb, and the stuff you post is often quite relevant to our work, but as long as you post this stuff the way you do the only thing you will achieve quickly is that we'll ignore what you say, and that you get moderated again on mailing lists like systemd-devel like you already got twice. That is a loss, since there are things in what you say that I find quite relevant. But jeesus, it's so frickin annoying to deal with you and your writings, you know that?
if it would not feel systemd upstream does not care what happens left and right maybe the feedback would differnt
did you ever consider that?
https://bugzilla.redhat.com/show_bug.cgi?id=1072368 https://bugzilla.redhat.com/show_bug.cgi?id=1010572 https://bugzilla.redhat.com/show_bug.cgi?id=626477 https://bugzilla.redhat.com/show_bug.cgi?id=1047148 https://bugzilla.redhat.com/show_bug.cgi?id=1024379
Quite frankly, these all are fixed upstream
upstream does not help in case of Fedora
if the number one downstream distribution can't manage them upstream should consider that thigs are not working properly
or relatively harmless
define harmless
* frozen terminals in case of reboot remote servers is not harmless * burry relevant messages in a permanent flood is not harmless
things like where you'd prefer us to generate less log messages. Making such a fuss about these things is way over the top. Not a single one of these you posted is about actual functionality bugs not getting fixed upstream.
if you ever would have managed 10, 20, 30 servers where you do things like distribute-command "cat /var/log/messages" and expect to not get burried by irrelevant notices your point of view would be different
the problem is that you insist in journald and filtering while you refuse to understand larger setups
Please try to understand that things like this don't get the highest priority on our TODO list. Also, you don't have the privilige of being entitled to get your own private bugs fixed immeidately, really
i understand that, but you need to understand the reaction because in fact i do not take anybody serious not face things like https://bugzilla.redhat.com/show_bug.cgi?id=1010572 after the first boot - why? because that means the person never looks at his logs, serious sysadmins do
Yes, it would be nice if we fix them, but open source is really not just about you demanding things and we giving it to you
you don't get the point
systemd in F19 is working perfect systemd in F20 is horrible
i do not demand to introduce all that things which are the reason for now i not consider to upgrade any production machine to F20
It's a two way street, so instead of all the negative energy you spend bitching about things, how about actually doing something really constructive, figuring out a patch or so, for the relevant things, and submitting that?
and that is the problem with you attitude
* making changes left and right * not care about the impact of users * demand users to chew the reuslt or fix it themslef
Am 24.03.2014 21:51, schrieb Lennart Poettering:
On Mon, 24.03.14 21:45, Reindl Harald (h.reindl@thelounge.net) wrote:
and that is the problem with you attitude
Okeydokey, as you wish, you are now in my killfile
so what - why should i case about beeing in the killfile of people which can't stand criticism - other than you i can and be not that thin-skinned to need a killfile
On Mon, Mar 24, 2014 at 07:18:58PM +0100, Lennart Poettering wrote:
I am not going to file a feature for Fedora, to remove support for it entirely across the whole distro. I still think dropping it is the right thing to do, but I don't think it's a good use of my own time, to fight this through... I'd be happy though if somebody else would pick this up. Looking at the current FESCO members I am not entirely sure though whether a proposal to disable libwrap would have a chance in the current cycle though. (also, M. Miller kinda supported the proposal, which as history tells us means he probably is _not_ going to vote for it in the end...)
I guess I wasn't clear enough with you last time around. I thought I was more clear this time, but I guess I'll repeat: demanding "instant progress or nothing" doesn't get you as far as breaking things down into manageable steps and executing on each one. Sometimes, we need to bite the bullet and make a big painful cut, but usually we don't. When it's something like this, (or like the default MTA, or like logging -- where there's no particular urgency to make the change and there are reasonable Fedora contributors with reservations, I'm absolutely in favor of phased approach.
It's a pity though that nobody in Fedora is actively working on getting rid of legacy cruft. I really wished we had some people who oversee deprecating things more proactively, figure out how to deprecate things, write stub code to provide smooth transitions, write release notes and so on. Being at the bleeding edge of things also means deciding that some things really should go, from time to time...
I absolutely agree. This should be an important fuction of the Base Design working group. Before that, we also have a "Minimal Core" SIG with some interest but not much activity (that last may somewhat be my fault, since I kicked it off but my attention wandered).
Besides deprecating
old cruft like libwrap, this would also mean removing all the old crap from comps "standard" that we still install by default (894110)...
https://bugzilla.redhat.com/show_bug.cgi?id=894110
There wasn't previously a great framework for discussing this kind of thing. I hope that we do have that now. And just as you don't have to be a voting WG member to contribute to a product SIG, it would be helpful for anyone interested in this to provide constructive feedback to the Base Design group.
On Mon, Mar 24, 2014 at 3:07 PM, Matthew Miller mattdm@fedoraproject.org wrote:
On Mon, Mar 24, 2014 at 07:18:58PM +0100, Lennart Poettering wrote:
It's a pity though that nobody in Fedora is actively working on getting rid of legacy cruft. I really wished we had some people who oversee deprecating things more proactively, figure out how to deprecate things, write stub code to provide smooth transitions, write release notes and so on. Being at the bleeding edge of things also means deciding that some things really should go, from time to time...
I absolutely agree. This should be an important fuction of the Base Design working group. Before that, we also have a "Minimal Core" SIG with some interest but not much activity (that last may somewhat be my fault, since I kicked it off but my attention wandered).
You should really make a point of telling the Base WG this directly. Nobody in that WG even has something like this on their radar. At the moment it's just reviewing Tech Specs looking for Base work items (none found), discussing the concept of Base, and doing some dependency trimming.
Besides deprecating
old cruft like libwrap, this would also mean removing all the old crap from comps "standard" that we still install by default (894110)...
https://bugzilla.redhat.com/show_bug.cgi?id=894110
There wasn't previously a great framework for discussing this kind of thing. I hope that we do have that now. And just as you don't have to be a voting WG member to contribute to a product SIG, it would be helpful for anyone interested in this to provide constructive feedback to the Base Design group.
It would if the Base Design group thought that kind of thing was something FESCo wanted them to tackle. Please help the WG more clearly define the things they're supposed to be doing. IMO, the Base WG seems to have been created because someone thought it would be a good idea to have one without really elaborating on what that meant. As a byproduct, the WG is left to figure it out on their own and hasn't really firmly grasped what it's for.
It is the WG equivalent of staring at the stars and wondering "why do I exist?".
josh
On 03/24/2014 06:18 PM, Lennart Poettering wrote:
It's a pity though that nobody in Fedora is actively working on getting rid of legacy cruft. I really wished we had some people who oversee deprecating things more proactively, figure out how to deprecate things, write stub code to provide smooth transitions, write release notes and so on.
Those people get tired having to constantly fight things through the bureaucracy and downstream distribution and it's clone too.
Being at the bleeding edge of things also means deciding that some things really should go, from time to time... Besides deprecating old cruft like libwrap, this would also mean removing all the old crap from comps "standard" that we still install by default (894110)...
For the record Fedora is not a bleeding edge distro anymore or first in anything.
The distribution that is and has been for quite sometime is Arch but I'm pretty sure you already knew that.
JBG
Am 24.03.2014 20:30, schrieb Jóhann B. Guðmundsson:
Being at the bleeding edge of things also means deciding that some things really should go, from time to time... Besides deprecating old cruft like libwrap, this would also mean removing all the old crap from comps "standard" that we still install by default (894110)...
For the record Fedora is not a bleeding edge distro anymore or first in anything
maybe some people should consider the difference between "leading" and "bleeding"
smart: leading if things are ready dumb: bleeding for any price
if you think people are happily bleeding all the time you need a lot to learn people accept bleeding for good reasons from time to time but not always with no real benefit and if you want a distribution where users always bleed go ahead but don't try to damage the way Fedora goes to become a serious useable distribution over the time
if users bleed to much they dirft away before they die
On Mon, Mar 24, 2014 at 09:17:20PM +0100, Reindl Harald wrote:
For the record Fedora is not a bleeding edge distro anymore or first in anything
maybe some people should consider the difference between "leading" and "bleeding" smart: leading if things are ready dumb: bleeding for any price
I agree with Harald here. I think some people have always wanted it to be, but Fedora never really has been chartered to be "bleeding". To quote the "first" foundation more fully:
First represents our commitment to innovation. We are not content to let others do all the heavy lifting on our behalf; we provide the latest in stable and robust, useful, and powerful free software in our Fedora distribution.
Note "latest in stable and robust", not "latest bleeding edge". There is supposed to be a balance here.
On Tue, 2014-03-25 at 09:24 -0400, Matthew Miller wrote:
I agree with Harald here. I think some people have always wanted it to be, but Fedora never really has been chartered to be "bleeding". To quote the "first" foundation more fully:
First represents our commitment to innovation. We are not content to let others do all the heavy lifting on our behalf; we provide the latest in stable and robust, useful, and powerful free software in our Fedora distribution.
Note "latest in stable and robust", not "latest bleeding edge". There is supposed to be a balance here.
I think Fedora is hitting that balance relatively well when it releases new distros. There are always packages with serious bugs, and there are always packagers that choose to ship development snapshots, but for the most part, new releases are not the problem. I do not consider a new Fedora release to be any less stable than comparable distributions. On the contrary, I think the QA team does a very good job of finding and resolving blocker bugs, a process no other comparable distro has.
The problem is that stable releases don't stay stable. The updates pipe turns on prior to day one, and maintainers can release whatever they want onto the distribution. We see unjustified major version updates because someone requests a backport of something shiny and new, and with them come major new bugs, or even major dependency issues.
The existing update policy [1] does a good job of describing what is appropriate for a stable release update. It's notably much more lenient than any other major distribution. You cannot get even a minor (bugfix) version update into Ubuntu/Debian/openSUSE/(Mageia?) just because: you usually need to pick a change that you really want, and backport just that change. In contrast, minor version updates are fine for Fedora: our update policy only prevents updates to major releases with new features, and even then, qualifies this with language like "if at all possible."
The existing update policy does a bad job of describing when an appropriate update is suitable for release. There's really no good reason a noncritical update can go straight to stable after less than a week in updates-testing, for example. The existing update policy is also not properly enforced. (I could give examples, but I don't much see the point in picking on individual packages here: suffice to say that I don't think FESCO is asked to approve all updates that require approval.) Lastly, there aren't enough automated checks on the updates: an update that accidentally adds a dependency on a new graphical program should be caught automatically, for example.
Ideally, there would be someone other than the package maintainer who has to press the Release Update button: not to be an update Nazi, but to make sure the basic rules are followed, and to catch updates that aren't justified by the changelog.
$0.02
On 03/25/2014 01:24 PM, Matthew Miller wrote:
On Mon, Mar 24, 2014 at 09:17:20PM +0100, Reindl Harald wrote:
For the record Fedora is not a bleeding edge distro anymore or first in anything
maybe some people should consider the difference between "leading" and "bleeding" smart: leading if things are ready dumb: bleeding for any price
I agree with Harald here. I think some people have always wanted it to be, but Fedora never really has been chartered to be "bleeding". To quote the "first" foundation more fully:
First represents our commitment to innovation. We are not content to let others do all the heavy lifting on our behalf; we provide the latest in stable and robust, useful, and powerful free software in our Fedora distribution.
Note "latest in stable and robust", not "latest bleeding edge". There is supposed to be a balance here.
Leading and bleeding go hand in hand being "first"
In this particular case we already are years behind Arch and soon to be behind OpenSuse and others aswell.
So if this is the case when people want to modernize and cleanup the distribution then perhaps it's time for the board revisit and redefine the foundation for firs so contributors can avoid Fedora and move to more acceptable distribution of their contributions like Arch if they want to be part of distribution that is leading and is "first".
JBG
Am 25.03.2014 15:22, schrieb Jóhann B. Guðmundsson:
On 03/25/2014 01:24 PM, Matthew Miller wrote:
On Mon, Mar 24, 2014 at 09:17:20PM +0100, Reindl Harald wrote:
For the record Fedora is not a bleeding edge distro anymore or first in anything
maybe some people should consider the difference between "leading" and "bleeding" smart: leading if things are ready dumb: bleeding for any price
I agree with Harald here. I think some people have always wanted it to be, but Fedora never really has been chartered to be "bleeding". To quote the "first" foundation more fully:
First represents our commitment to innovation. We are not content to let others do all the heavy lifting on our behalf; we provide the latest in stable and robust, useful, and powerful free software in our Fedora distribution.
Note "latest in stable and robust", not "latest bleeding edge". There is supposed to be a balance here.
Leading and bleeding go hand in hand being "first"
no, the is a sharp line to draw
In this particular case we already are years behind Arch and soon to be behind OpenSuse and others aswell
as long as you do not make any points this is FUD
So if this is the case when people want to modernize and cleanup the distribution then perhaps it's time for the board revisit and redefine the foundation for firs so contributors can avoid Fedora and move to more acceptable distribution of their contributions like Arch if they want to be part of distribution that is leading and is "first"
stop your destructive FUD, without users developers and contributors are *meaningless* and with throwing alpha-state software to the users and make them bleed all the time you will end in no users at all
if you don't understand that, don't care for users and don't like Fedora as you statet often enough because you hate Redhat, well, you know what you have to do
On 03/25/2014 02:41 PM, Reindl Harald wrote:
stop your destructive FUD, without users developers and contributors are*meaningless* and with throwing alpha-state software to the users and make them bleed all the time you will end in no users at all
if you don't understand that, don't care for users and don't like Fedora as you statet often enough because you hate Redhat, well, you know what you have to do
I think you should keep your mouth shut accusing me of destructive FUD
I'm not the one that is calling developers idiots [1] then complain about them adding you to their killfile list [2]
The fact is all the distribution are deprecating tcpwrappers and denyhosts along with it including Debian [1] due to it being maintained and a security risk
But hey let's keep Fedora out of sync with other distribution and hold progress back to please your usecase
JBG
1. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=7327122 2. https://lists.fedoraproject.org/pipermail/devel/2014-March/197093.html 3. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=732712
Everyone in this thread: Please re-read our code of conduct (in the footer of every single message).
Stop attacking people. Please stick to constructive comments about ideas instead.
kevin
Am 25.03.2014 15:54, schrieb Jóhann B. Guðmundsson:
On 03/25/2014 02:41 PM, Reindl Harald wrote:
stop your destructive FUD, without users developers and contributors are *meaningless* and with throwing alpha-state software to the users and make them bleed all the time you will end in no users at all
if you don't understand that, don't care for users and don't like Fedora as you statet often enough because you hate Redhat, well, you know what you have to do
I think you should keep your mouth shut accusing me of destructive FUD
i can seek in the archives how often you attack Redhat and so on https://lists.fedoraproject.org/pipermail/devel/2013-February/177915.html
I'm not the one that is calling developers idiots [1]
you state [1] two times and list it once with a broken link
here we go: https://bugzilla.redhat.com/show_bug.cgi?id=1072368
nobody right in his mind states *18* loglines for every single cronjob are fine - multiply that with 85 cronjobs on our main server, some of them every minute for good reasons
then you have 2 additional lines in /var/log/cron and a few in /var/log/secure - frankly call that a self-DOS in case of a central logserver for 30 machines with a database backend to feed own filter and search applications _______________________________________________
well deserved in case "flood logs is fine" while that is a naked Rawhide VM and a production server with cronjobs would produce many ten if not hundret thousands of log messages leading to no longer face serious ones and without useful prefixes to filter them outin rsyslog.conf
then complain about them adding you to their killfile list [2]
the problem with Lennart is that he can't stand *any* critism and is pissed off or ignoring anything people tell him
bugreports are ignored over months and then after list them again all commented within minutes - fine
no reply - interesting http://www.spinics.net/lists/fedora-devel/msg196606.html
The fact is all the distribution are deprecating tcpwrappers and denyhosts along with it including Debian [1] due to it being maintained and a security risk
don't mix two things where is the security relevant bug of tcpwrappers?
"it did not get new versions" is not a problem
only people like you don't understand that things which ain't broken don't need to be fixed and get new bugs due that
But hey let's keep Fedora out of sync with other distribution and hold progress back to please your usecase
*what progress* *what are you missing*
is broken and don't exist at debian nor at Redhat
Lennart Poettering (mzerqung@0pointer.de) said:
this through... I'd be happy though if somebody else would pick this up. Looking at the current FESCO members I am not entirely sure though whether a proposal to disable libwrap would have a chance in the current cycle though. (also, M. Miller kinda supported the proposal, which as history tells us means he probably is _not_ going to vote for it in the end...)
It's a pity though that nobody in Fedora is actively working on getting rid of legacy cruft. I really wished we had some people who oversee deprecating things more proactively, figure out how to deprecate things, write stub code to provide smooth transitions, write release notes and so on.
Well, if you're going to passive-agressively shittalk anyone who tries to do so in a way you disagree with (as you do above), I'm not sure why anyone would willingly take you up on that offer.
In any case, yes, concentrating on how to deprecate, providing smooth transitions, release notes, etc. are all important things to think about when discussing removing a feature, and framing the discussions in terms of "it's crap code, it doesn't really do what people are trying to use it for, no one should use it" accomplishes none of those items.
Bill
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.
I have decided now to drop all support for tcpwrap from systemd, for the next release. For those who believe that tcpd is really a good idea (yuck!) not much is lost though, they can just plug in tcpd into systemd, the way they did it with good old inetd, too, hence we are not taking anything away there, we are pretty much compatible with what inetd supported there (or actually: didn't support there).
I am not going to file a feature for Fedora, to remove support for it entirely across the whole distro. I still think dropping it is the right thing to do, but I don't think it's a good use of my own time, to fight this through... I'd be happy though if somebody else would pick this up. Looking at the current FESCO members I am not entirely sure though whether a proposal to disable libwrap would have a chance in the current cycle though. (also, M. Miller kinda supported the proposal, which as history tells us means he probably is _not_ going to vote for it in the end...)
It's a pity though that nobody in Fedora is actively working on getting rid of legacy cruft. I really wished we had some people who oversee deprecating things more proactively, figure out how to deprecate things, write stub code to provide smooth transitions, write release notes and so on. Being at the bleeding edge of things also means deciding that some things really should go, from time to time... Besides deprecating old cruft like libwrap, this would also mean removing all the old crap from comps "standard" that we still install by default (894110)...
Interesting! You sent the email starting this thread a mere 4 days ago, two of those a weekend. You've not given it a chance to even go to FESCo meeting for discussion. Did you send it in the same way to the rest of the distros that depend, or are soon to depend on, systemd now.... SuSE, Arch, Debian, Ubuntu etc giving them no chance to discuss the impact before you unceremoniously tear a feature, for some, out?
Ultimately I've long stopped using tcpwrappers (a decade or so ago in fact) so it doesn't bother me what so ever but I know of a LOT of people that use it, rightly or wrongly, extensively.
systemd is now, or soon will be, a core component of pretty much all major and minor distributions out there and it's no longer just about you Lennart and your thoughts of whether it's "Yuck!" or not, you are now similar to the kernel and like the kernel you should have a proper deprecation process that is not just what you, Kay and who ever the main developers decide is cool or not at the time. You should give us and distributions in general more than 4 days to deal with what lives or not. Ultimately systemd is no longer in nappies and is all grown up, while you are still it's father it's now a teenager and needs to be somewhat independent of it's father, it has friends that now depend on it and there's should be a central place where these architectural changes and deprecation intentions are announced, discussed and in the case of deprecation given more than 4 days before removal.
Peter
Am 24.03.2014 22:22, schrieb Peter Robinson:
Interesting! You sent the email starting this thread a mere 4 days ago, two of those a weekend. You've not given it a chance to even go to FESCo meeting for discussion. Did you send it in the same way to the rest of the distros that depend, or are soon to depend on, systemd now.... SuSE, Arch, Debian, Ubuntu etc giving them no chance to discuss the impact before you unceremoniously tear a feature, for some, out?
be careful with criticism or you get killfild by Lennart
On Mon, 24.03.14 21:22, Peter Robinson (pbrobinson@gmail.com) wrote:
Interesting! You sent the email starting this thread a mere 4 days ago, two of those a weekend. You've not given it a chance to even go to FESCo meeting for discussion. Did you send it in the same way to the rest of the distros that depend, or are soon to depend on, systemd now.... SuSE, Arch, Debian, Ubuntu etc giving them no chance to discuss the impact before you unceremoniously tear a feature, for some, out?
I quickly got reports back from the other distros, and even reported it back here...
I am not "tearing" the thing, I am just saying that I don't have the time to work on it in the Fedora scale.
systemd is now, or soon will be, a core component of pretty much all major and minor distributions out there and it's no longer just about you Lennart and your thoughts of whether it's "Yuck!" or not, you are now similar to the kernel and like the kernel you should have a proper deprecation process that is not just what you, Kay and who ever the main developers decide is cool or not at the time. You should give us and distributions in general more than 4 days to deal with what lives or not. Ultimately systemd is no longer in nappies and is all grown up, while you are still it's father it's now a teenager and needs to be somewhat independent of it's father, it has friends that now depend on it and there's should be a central place where these architectural changes and deprecation intentions are announced, discussed and in the case of deprecation given more than 4 days before removal.
We *did* get feedback from distros first, and we provide an alternative to use tcpwrap with systemd even further on (via tcpd), so I really don't see what you are upset about.
Lennart
On Mon, 2014-03-24 at 21:22 +0000, Peter Robinson wrote:
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.
I have decided now to drop all support for tcpwrap from systemd, for the next release. For those who believe that tcpd is really a good idea (yuck!) not much is lost though, they can just plug in tcpd into systemd, the way they did it with good old inetd, too, hence we are not taking anything away there, we are pretty much compatible with what inetd supported there (or actually: didn't support there).
I am not going to file a feature for Fedora, to remove support for it entirely across the whole distro. I still think dropping it is the right thing to do, but I don't think it's a good use of my own time, to fight this through... I'd be happy though if somebody else would pick this up. Looking at the current FESCO members I am not entirely sure though whether a proposal to disable libwrap would have a chance in the current cycle though. (also, M. Miller kinda supported the proposal, which as history tells us means he probably is _not_ going to vote for it in the end...)
It's a pity though that nobody in Fedora is actively working on getting rid of legacy cruft. I really wished we had some people who oversee deprecating things more proactively, figure out how to deprecate things, write stub code to provide smooth transitions, write release notes and so on. Being at the bleeding edge of things also means deciding that some things really should go, from time to time... Besides deprecating old cruft like libwrap, this would also mean removing all the old crap from comps "standard" that we still install by default (894110)...
Interesting! You sent the email starting this thread a mere 4 days ago, two of those a weekend. You've not given it a chance to even go to FESCo meeting for discussion. Did you send it in the same way to the rest of the distros that depend, or are soon to depend on, systemd now.... SuSE, Arch, Debian, Ubuntu etc giving them no chance to discuss the impact before you unceremoniously tear a feature, for some, out?
Ultimately I've long stopped using tcpwrappers (a decade or so ago in fact) so it doesn't bother me what so ever but I know of a LOT of people that use it, rightly or wrongly, extensively.
systemd is now, or soon will be, a core component of pretty much all major and minor distributions out there and it's no longer just about you Lennart and your thoughts of whether it's "Yuck!" or not, you are now similar to the kernel and like the kernel you should have a proper deprecation process that is not just what you, Kay and who ever the main developers decide is cool or not at the time. You should give us and distributions in general more than 4 days to deal with what lives or not. Ultimately systemd is no longer in nappies and is all grown up, while you are still it's father it's now a teenager and needs to be somewhat independent of it's father, it has friends that now depend on it and there's should be a central place where these architectural changes and deprecation intentions are announced, discussed and in the case of deprecation given more than 4 days before removal.
+1
Simo,
On 03/24/2014 09:22 PM, Peter Robinson wrote:
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.
I have decided now to drop all support for tcpwrap from systemd, for the next release. For those who believe that tcpd is really a good idea (yuck!) not much is lost though, they can just plug in tcpd into systemd, the way they did it with good old inetd, too, hence we are not taking anything away there, we are pretty much compatible with what inetd supported there (or actually: didn't support there).
I am not going to file a feature for Fedora, to remove support for it entirely across the whole distro. I still think dropping it is the right thing to do, but I don't think it's a good use of my own time, to fight this through... I'd be happy though if somebody else would pick this up. Looking at the current FESCO members I am not entirely sure though whether a proposal to disable libwrap would have a chance in the current cycle though. (also, M. Miller kinda supported the proposal, which as history tells us means he probably is _not_ going to vote for it in the end...)
It's a pity though that nobody in Fedora is actively working on getting rid of legacy cruft. I really wished we had some people who oversee deprecating things more proactively, figure out how to deprecate things, write stub code to provide smooth transitions, write release notes and so on. Being at the bleeding edge of things also means deciding that some things really should go, from time to time... Besides deprecating old cruft like libwrap, this would also mean removing all the old crap from comps "standard" that we still install by default (894110)...
Interesting! You sent the email starting this thread a mere 4 days ago, two of those a weekend. You've not given it a chance to even go to FESCo meeting for discussion. Did you send it in the same way to the rest of the distros that depend, or are soon to depend on, systemd now.... SuSE, Arch, Debian, Ubuntu etc giving them no chance to discuss the impact before you unceremoniously tear a feature, for some, out?
Ultimately I've long stopped using tcpwrappers (a decade or so ago in fact) so it doesn't bother me what so ever but I know of a LOT of people that use it, rightly or wrongly, extensively.
systemd is now, or soon will be, a core component of pretty much all major and minor distributions out there and it's no longer just about you Lennart and your thoughts of whether it's "Yuck!" or not, you are now similar to the kernel and like the kernel you should have a proper deprecation process that is not just what you, Kay and who ever the main developers decide is cool or not at the time. You should give us and distributions in general more than 4 days to deal with what lives or not. Ultimately systemd is no longer in nappies and is all grown up, while you are still it's father it's now a teenager and needs to be somewhat independent of it's father, it has friends that now depend on it and there's should be a central place where these architectural changes and deprecation intentions are announced, discussed and in the case of deprecation given more than 4 days before removal.
I'm not sure where this is coming from but Arch removed this 3 years ago and the original request of removal from upstream came from opensuse with Debian responding they will be keeping this around for a while ( it will be like 4 years in my gestimation for Debian to catch up with systemd integration anyway so this is hardly a pressing concern for them ) so Lennart was being rather conservative of it's removal upstream atleast not without checking with us ( Fedora ) first since we were the remaining part responding of the "big distro's" to his "heads up" .
From broader view this boils down to how long should unmaintained core os components be kept around, which is something that should be hashed out among relevant upstreams in next plumbers session to establish a clear path forward and arguably upstreams should be responsible to make the decisions when things should be deprecated forcing downstream to either adapt new modern way's or maintain stuff downstream with themselves chose they do so instead of adapt.
By the way the kernel does not have a proper deprecation process which is accurately reflected in all the code that is bit-rotting there so it's not the holy grail of code maintenance as you let it out to be.
It lacks it's Boothby's to snip out the dead branches as much as we do here with us.
JBG
Am 24.03.2014 22:53, schrieb Jóhann B. Guðmundsson:
By the way the kernel does not have a proper deprecation process which is accurately reflected in all the code that is bit-rotting there so it's not the holy grail of code maintenance as you let it out to be
the kernel at least has the rule "if it break something it has to be reverted" a mantra from which *many* other projects could learn
why?
because Linus is not acting like a blind butcher and aware of his great responsibility which is the logical result of great power
2014-03-24 22:53 GMT+01:00 "Jóhann B. Guðmundsson" johannbg@gmail.com:
systemd is now, or soon will be, a core component of pretty much all
major and minor distributions out there and it's no longer just about you Lennart and your thoughts of whether it's "Yuck!" or not, you are now similar to the kernel and like the kernel you should have a proper deprecation process that is not just what you, Kay and who ever the main developers decide is cool or not at the time. You should give us and distributions in general more than 4 days to deal with what lives or not. Ultimately systemd is no longer in nappies and is all grown up, while you are still it's father it's now a teenager and needs to be somewhat independent of it's father, it has friends that now depend on it and there's should be a central place where these architectural changes and deprecation intentions are announced, discussed and in the case of deprecation given more than 4 days before removal.
<snip>
From broader view this boils down to how long should unmaintained core os components be kept around
The way I read Peter's mail, he is referring to TCPWrapName in systemd, removing it less than 4 years after its introduction, with no advance notification to users. (To be clear, this is not a Fedora-specific concern unless someone wants to make it one, and I don't.)
Independently, looking at https://bugzilla.redhat.com/bugzilla/buglist.cgi?component=tcp_wrappers , it doesn't seem that tcp_wrappers need much maintenance.
, which is something that should be hashed out among relevant upstreams in next plumbers session to establish a clear path forward and arguably upstreams should be responsible to make the decisions when things should be deprecated forcing downstream to either adapt new modern way's or maintain stuff downstream with themselves chose they do so instead of adapt.
That doesn't work. Unfortunately a common reason to deprecate a component is that the upstream has gone away or become inactive, in which case we can't expect that same upstream to take action to coordinate a deprecation.
And in any case, we shouldn't start with the default assumption that any published Open Source component is by default stable and recommended to be relied upon by other applications, and only "blacklist" those that are known to be deprecated; in fact many Open Source codebases are private codebases published "just in case others find them useful".
We should rather use a "whitelist" approach, choosing and listing components known to be competently designed and likely to be well-maintained in the future, and taking extra care to help them stay that way--moving towards an actual declared API of the OS.
(The Base WG has, as one its goals:
Based on feedback from other WGs, provide a API and/or ABI stability for a specific release rather than simply package versions/releases
)
By the way the kernel does not have a proper deprecation process which is
accurately reflected in all the code that is bit-rotting there so it's not the holy grail of code maintenance as you let it out to be.
The kernel has built a reputation for having a very simple deprecation process: "Don't" :) And actually it does have a "proper" deprecation process beside that: http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Document... I'm not entirely sure how popular / comprehensive this is, at last one time this seemed to be undesirable, opposing the "Don't" approach.) Mirek
On 03/24/2014 10:23 PM, Miloslav Trmač wrote:
That doesn't work.
On the contrary if it did not the business module Red Hat is build upon would not exist since Red Hat is making money out of stability promises to it's customers which upstream is not providing right.
Unfortunately a common reason to deprecate a component is that the upstream has gone away or become inactive, in which case we can't expect that same upstream to take action to coordinate a deprecation.
Here we are talking about various upstreams that make up the core/baseOS not single entity.
Now if an upstream for a component is dead in every sense of the word as in not being actively maintained anywhere by anyone it should be removed because that in itself is the signal for deprecation.
If people oppose said removal they simple should have to step up and start actively maintain that component thus bringing life to it again for those users that continue to use it as in if upstream has gone away and someone or some downstream distribution continues to patch that component it effectively has become the new upstream and the circle of life and the ecosystem surrounding that component continues.
(The Base WG has, as one its goals:
Based on feedback from other WGs, provide a API and/or ABI stability for a specific release rather than simply package versions/releases
)
I eagerly await how they plan on succeed doing that and how they are going to overcome certain obstacles they will be faced with solving while doing so.
By the way the kernel does not have a proper deprecation process which is accurately reflected in all the code that is bit-rotting there so it's not the holy grail of code maintenance as you let it out to be.
The kernel has built a reputation for having a very simple deprecation process: "Don't" :)
Right which is bound to catch up with them ( it's unavoidable with evolution that disruptive changes will happen ) and arguably already has.
JBG
On Thu, 20 Mar 2014 18:34:22 +0100 Lennart Poettering mzerqung@0pointer.de wrote:
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...
I use tcpwrappers through denyhosts, which write out /etc/hosts.deny. Then openssh-server then uses the tcpwrappers to apply the rules (AFAIK). When I investigated it, denyhosts was superior to fail2ban due to the latter doing some crazy stuff with iptables that made me uncomfortable. Also, this:
Installing: fail2ban noarch 0.9-0.3.git1f1a561.fc20 fedora 261 k Installing for dependencies: ed x86_64 1.10-1.fc20 updates 72 k gamin-python x86_64 0.1.10-15.fc20 fedora 34 k python-inotify noarch 0.9.4-4.fc20 fedora 49 k systemd-python x86_64 208-15.fc20 updates 80 k
I agree that tcpwrappers should die in favour of firewalls. Folks working on fail2ban are already considering integration with firewalld, which seems like a great idea. Too bad fail2ban is just as crusty as tcpwrappers. If we only had denyhosts that executed firewall-cmd...
-- Pete
On 03/28/2014 12:49 PM, Pete Zaitcev wrote:
On Thu, 20 Mar 2014 18:34:22 +0100 Lennart Poettering mzerqung@0pointer.de wrote:
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...
I use tcpwrappers through denyhosts, which write out /etc/hosts.deny. Then openssh-server then uses the tcpwrappers to apply the rules (AFAIK). When I investigated it, denyhosts was superior to fail2ban due to the latter doing some crazy stuff with iptables that made me uncomfortable. Also, this:
Installing: fail2ban noarch 0.9-0.3.git1f1a561.fc20 fedora 261 k Installing for dependencies: ed x86_64 1.10-1.fc20 updates 72 k gamin-python x86_64 0.1.10-15.fc20 fedora 34 k python-inotify noarch 0.9.4-4.fc20 fedora 49 k systemd-python x86_64 208-15.fc20 updates 80 k
I agree that tcpwrappers should die in favour of firewalls. Folks working on fail2ban are already considering integration with firewalld, which seems like a great idea. Too bad fail2ban is just as crusty as tcpwrappers. If we only had denyhosts that executed firewall-cmd...
-- Pete
What gives you the impression that fail2ban is "crusty"? It's being actively developed upstream and integrates with firewalld now. Are those particularly onerous dependencies?
Am 29.03.2014 15:54, schrieb Orion Poplawski:
What gives you the impression that fail2ban is "crusty"? It's being actively developed upstream and integrates with firewalld now. Are those particularly onerous dependencies?
and that is the problem / difference to tcpwrapper it integrates in the firewall / iptables
so you have *not* additional security layer, you have a single layer with a single point of failure and if iptables for hwatever reason does not work as it should you are lost
* bug in the rules failing iptables / forewalld to start * SELinux failing iptables / forewalld to start * bug in the iptables-rules render it useless (ACCEPT before REJECT/DROP)
if it ever comes to security you must not have a single protection layer and some others appearing to exist but rely on that single layer makes things even worser - /etc/hosts.deny works independent of SELinux or iptables
On Sat, Mar 29, 2014 at 10:54 AM, Orion Poplawski orion@cora.nwra.com wrote:
What gives you the impression that fail2ban is "crusty"? It's being actively developed upstream and integrates with firewalld now. Are those particularly onerous dependencies?
and with journal integration, python-inotify can probably go away, or at least become optional.
cheers,
m
On Thu, 20.03.14 18:34, Lennart Poettering (mzerqung@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.
To add to this old thread: OpenSSH has now also decided to drop tcpwrap.
https://lists.mindrot.org/pipermail/openssh-unix-dev/2014-April/032497.html
Some of the posts in this thread are actually quite entertaining.
For example, the first call of hosts_access() is setjmp(), which is just beautiful... We probably should make setjmp()-freeness a requirement for all code included in Fedora.
Lennart
On 24/04/14 15:13, Lennart Poettering wrote:
We probably should make setjmp()-freeness a requirement for all code included in Fedora.
Would it be worth the effort, and how feasible is it anyway? - Do we have any usage statistics? - How often do we see bugs caused by bad uses of setjmp/longjmp? - Is mitigation instead of blanket removal possible? - How likely is it that /all/ setjmp/longjmp uses can be reasonably replaced? - Is there existing upstream momentum to move away from setjmp/longjmp?
(I'm not against the idea but I think it deserves further discussion.)
Andy
Andrew Price writes:
On 24/04/14 15:13, Lennart Poettering wrote:
We probably should make setjmp()-freeness a requirement for all code included in Fedora.
Would it be worth the effort, and how feasible is it anyway?
- Do we have any usage statistics?
- How often do we see bugs caused by bad uses of setjmp/longjmp?
- Is mitigation instead of blanket removal possible?
- How likely is it that /all/ setjmp/longjmp uses can be reasonably replaced?
- Is there existing upstream momentum to move away from setjmp/longjmp?
(I'm not against the idea but I think it deserves further discussion.)
According to its manpage, setjmp and longjmp conform to C89, C99, and POSIX. I'm afraid I just can't wrap my brain around a concept of something that's good enough for POSIX, but not good enough for Fedora.
If we continue to think along these lines, we might as well ban any code that uses strcpy(), because of its inherent potential for buffer overflows, and exploitable code.
Can't wait for this latest howler from the great minds of Fedora to hit Slashdot.
Hi
On Sun, Apr 27, 2014 at 7:12 PM, Sam Varshavchik wrote:
According to its manpage, setjmp and longjmp conform to C89, C99, and POSIX. I'm afraid I just can't wrap my brain around a concept of something that's good enough for POSIX, but not good enough for Fedora.
Just because a API is widely available doesn't make it a good idea to use it. Lots of things that are standardized should never really be used but only retained for compatibility. ex: gets()
Rahul
Rahul Sundaram writes:
Hi
On Sun, Apr 27, 2014 at 7:12 PM, Sam Varshavchik wrote:
According to its manpage, setjmp and longjmp conform to C89, C99, and POSIX. I'm afraid I just can't wrap my brain around a concept of something that's good enough for POSIX, but not good enough for Fedora.
Just because a API is widely available doesn't make it a good idea to use it. Lots of things that are standardized should never really be used but only retained for compatibility. ex: gets()
That old tune has accumulated a couple of decades' worth of dust, by now, and I always found the ominous warning in the man page to be quite funny.
On Sun, 2014-04-27 at 19:12 -0400, Sam Varshavchik wrote:
Can't wait for this latest howler from the great minds of Fedora to hit Slashdot.
NECRO ALERT
Still catching up on devel@ archives. This was an interesting thread to read in retrospect (and much of it over my head), but I was particularly disappointed to see this.
On the one hand, this is *kind of* a legitimate concern. The tech press - especially the more disreputable end of it - tends to read our lists and forums and even, on occasion, IRC, and post up ridiculous stories based on misunderstandings of what it finds.
On the other hand, I think it'd be a *terrible* idea to start self-censoring our thoughts based on how they might look as a Slashdot or Phoronix (or, gods forbid, Varghese) story. That'd be an awful 'chilling effect'.
Sam, this was clearly a half-baked thought Lennart threw out in passing. It wasn't a formal proposal. Andrew thought it was interesting enough to have a kick-around thread. Various smart folks considered it and there was a fairly solid consensus that it wasn't a great idea. And that's as far as it went. That seems entirely reasonable to me. It'd be kind of sad if we couldn't kick around stuff like this on a list like devel@. It's bad enough that Slashdot et al pick this stuff up and then badly misrepresent it; having our own list participants invoke/encourage that kind of thing doesn't seem at all useful to me.
Adam Williamson writes:
Sam, this was clearly a half-baked thought Lennart threw out in passing. It wasn't a formal proposal.
I don't think there was any danger of anyone possibly considering that.
It's bad enough that Slashdot et al pick this stuff up and then badly misrepresent it; having our own list participants invoke/encourage that kind of thing doesn't seem at all useful to me.
I don't think a message here can either make that happen or not make that happen. But if it were to happen, whose fault would that ultimately be?(*)
(*)And, I should also say that I'm trying to censor myself. Just now, and before – the original version of what I wrote was …longer.
On Wed, 2014-06-04 at 21:15 -0400, Sam Varshavchik wrote:
Adam Williamson writes:
Sam, this was clearly a half-baked thought Lennart threw out in passing. It wasn't a formal proposal.
I don't think there was any danger of anyone possibly considering that.
It's bad enough that Slashdot et al pick this stuff up and then badly misrepresent it; having our own list participants invoke/encourage that kind of thing doesn't seem at all useful to me.
I don't think a message here can either make that happen or not make that happen.
I think it can make it *slightly more likely* to happen.
But if it were to happen, whose fault would that ultimately be?(*)
Slashdot's, of course. But when we know something is a bad thing, if we can make it less likely to happen without losing anything of value (i.e. by not posting stuff like "just wait till slashdot gets a hold of this!") we might as well.
2014-04-28 00:02 keltezéssel, Andrew Price írta:
On 24/04/14 15:13, Lennart Poettering wrote:
We probably should make setjmp()-freeness a requirement for all code included in Fedora.
Would it be worth the effort, and how feasible is it anyway?
- Do we have any usage statistics?
- How often do we see bugs caused by bad uses of setjmp/longjmp?
- Is mitigation instead of blanket removal possible?
- How likely is it that /all/ setjmp/longjmp uses can be reasonably replaced?
- Is there existing upstream momentum to move away from setjmp/longjmp?
(I'm not against the idea but I think it deserves further discussion.)
Andy
Just one datapoint: have fun rewriting PostgreSQL's error handling while still keeping it portable and acceptable upstream. Not to mention Cerberus (a.k.a. Tom Lane) who guards that entrance, reads this list and IIRC is a Red Hat employee at the moment. :-)
Best regards, Zoltán Böszörményi
Hi
On Mon, Apr 28, 2014 at 3:47 AM, Zoltan Boszormenyi wrote:
Just one datapoint: have fun rewriting PostgreSQL's error handling while still keeping it portable and acceptable upstream. Not to mention Cerberus (a.k.a. Tom Lane) who guards that entrance, reads this list and IIRC is a Red Hat employee at the moment. :-)
Not that it matters much to your point but he doesn't work for Red Hat anymore
http://www.wired.com/2013/05/salesforce-tom-lane/
Rahul
On Mon, Apr 28, 2014 at 09:47:53 +0200, Zoltan Boszormenyi zboszor@freemail.hu wrote:
Just one datapoint: have fun rewriting PostgreSQL's error handling while still keeping it portable and acceptable upstream. Not to mention Cerberus (a.k.a. Tom Lane) who guards that entrance, reads this list and IIRC is a Red Hat employee at the moment. :-)
I don't know if he still reads this list, but he changed employment about one year ago.
On Sun, 2014-04-27 at 23:02 +0100, Andrew Price wrote:
On 24/04/14 15:13, Lennart Poettering wrote:
We probably should make setjmp()-freeness a requirement for all code included in Fedora.
Would it be worth the effort, and how feasible is it anyway?
setjmp and longjmp are tools, that one may use in a good or bad way. Along the same lines one could argue for dropping programs that use goto in Fedora (because everyone knows that goto is bad).
To the point, if a program uses setjmp and longjmp it is often that there was no other way to do it. You cannot for example have a co-routine/fiber implementation in C without setjmp() and longjmp().
regards, Nikos
2014-04-28 09:52 keltezéssel, Nikos Mavrogiannopoulos írta:
On Sun, 2014-04-27 at 23:02 +0100, Andrew Price wrote:
On 24/04/14 15:13, Lennart Poettering wrote:
We probably should make setjmp()-freeness a requirement for all code included in Fedora.
Would it be worth the effort, and how feasible is it anyway?
setjmp and longjmp are tools, that one may use in a good or bad way. Along the same lines one could argue for dropping programs that use goto in Fedora (because everyone knows that goto is bad).
That would mean dropping the kernel, for one... :-)
To the point, if a program uses setjmp and longjmp it is often that there was no other way to do it. You cannot for example have a co-routine/fiber implementation in C without setjmp() and longjmp().
regards, Nikos
Dne 28.4.2014 09:52, Nikos Mavrogiannopoulos napsal(a):
On Sun, 2014-04-27 at 23:02 +0100, Andrew Price wrote:
On 24/04/14 15:13, Lennart Poettering wrote:
We probably should make setjmp()-freeness a requirement for all code included in Fedora.
I love the idea, but ...
Would it be worth the effort, and how feasible is it anyway?
setjmp and longjmp are tools, that one may use in a good or bad way. Along the same lines one could argue for dropping programs that use goto in Fedora (because everyone knows that goto is bad).
To the point, if a program uses setjmp and longjmp it is often that there was no other way to do it. You cannot for example have a co-routine/fiber implementation in C without setjmp() and longjmp().
For example, Ruby is using setjmp/longjmp to implement continuation [1], although I must admit it is quite a mess and it causes issues from time to time.
Vít
On 04/28/2014 09:52 AM, Nikos Mavrogiannopoulos wrote:
setjmp and longjmp are tools, that one may use in a good or bad way. Along the same lines one could argue for dropping programs that use goto in Fedora (because everyone knows that goto is bad).
All compliant uses of setjmp/longjmp can be replaced with C++ exceptions. I'm sure such a change would be somewhat controversial.
To the point, if a program uses setjmp and longjmp it is often that there was no other way to do it. You cannot for example have a co-routine/fiber implementation in C without setjmp() and longjmp().
I'm pretty sure it's one of the misuse scenarios. As specified, these functions cannot be used for unrestricted stack switching. Performance of setjmp/longjmp is also extremely poor because these functions save and restore much more context than needed.
On Mon, Apr 28, 2014 at 2:24 AM, Florian Weimer fweimer@redhat.com wrote:
On 04/28/2014 09:52 AM, Nikos Mavrogiannopoulos wrote:
setjmp and longjmp are tools, that one may use in a good or bad way.
Along the same lines one could argue for dropping programs that use goto in Fedora (because everyone knows that goto is bad).
All compliant uses of setjmp/longjmp can be replaced with C++ exceptions.
That might be true in C++, but it certainly isn't in C.
On Mon, Apr 28, 2014 at 09:52:36AM +0200, Nikos Mavrogiannopoulos wrote:
On Sun, 2014-04-27 at 23:02 +0100, Andrew Price wrote:
On 24/04/14 15:13, Lennart Poettering wrote:
We probably should make setjmp()-freeness a requirement for all code included in Fedora.
Would it be worth the effort, and how feasible is it anyway?
setjmp and longjmp are tools, that one may use in a good or bad way. Along the same lines one could argue for dropping programs that use goto in Fedora (because everyone knows that goto is bad).
To the point, if a program uses setjmp and longjmp it is often that there was no other way to do it. You cannot for example have a co-routine/fiber implementation in C without setjmp() and longjmp().
That's not correct - you can easily do coroutines using makecontext and swapcontext - both gtk-vnc and QEMU do this.
Regards, Daniel
On Mon, 2014-04-28 at 10:10 +0100, Daniel P. Berrange wrote:
To the point, if a program uses setjmp and longjmp it is often that there was no other way to do it. You cannot for example have a co-routine/fiber implementation in C without setjmp() and longjmp().
That's not correct - you can easily do coroutines using makecontext and swapcontext - both gtk-vnc and QEMU do this.
That's true and most modern co-routine libraries use makecontext and swapcontext. However that isn't part of C and their man page mentions "POSIX.1-2008 removes the specifications of makecontext() and swapcontext(), citing portability issues"...
regards, Nikos
On Sun, 2014-04-27 at 23:02 +0100, Andrew Price wrote:
On 24/04/14 15:13, Lennart Poettering wrote:
We probably should make setjmp()-freeness a requirement for all code included in Fedora.
Would it be worth the effort, and how feasible is it anyway?
I don't think it'd be worth the effort, and I think the burden of computing feasibility should rest with those who think it _is_ worth the effort.
A completely arbitrary datapoint:
dmt:~% file /lib64/* | grep ELF.*shared | cut -f 1 -d : | xargs nm -aDu | grep -c setjmp 79
At a minimum you'd have to rewrite freetype, have fun with that.
- ajax
On Mon, Apr 28, 2014 at 08:57:27AM -0400, Adam Jackson wrote:
On Sun, 2014-04-27 at 23:02 +0100, Andrew Price wrote:
On 24/04/14 15:13, Lennart Poettering wrote:
We probably should make setjmp()-freeness a requirement for all code included in Fedora.
Would it be worth the effort, and how feasible is it anyway?
I don't think it'd be worth the effort, and I think the burden of computing feasibility should rest with those who think it _is_ worth the effort.
Well, we could consider banning it from new packages and just let attrition take care of the rest.
--CJD
On Mon, 2014-04-28 at 09:58 -0400, Casey Dahlin wrote:
On Mon, Apr 28, 2014 at 08:57:27AM -0400, Adam Jackson wrote:
On Sun, 2014-04-27 at 23:02 +0100, Andrew Price wrote:
On 24/04/14 15:13, Lennart Poettering wrote:
We probably should make setjmp()-freeness a requirement for all code included in Fedora.
Would it be worth the effort, and how feasible is it anyway?
I don't think it'd be worth the effort, and I think the burden of computing feasibility should rest with those who think it _is_ worth the effort.
Well, we could consider banning it from new packages and just let attrition take care of the rest.
We could. I still wouldn't consider that a productive use of time. It's a rare API that can't be misused, I'd much prefer if we approached code quality by _actually reading the code_ rather than deciding with grep what we will and won't accept.
I know that's a radical idea, that as packagers we ought actually to know the language of the code being packaged, but I think it has merit.
- ajax
On 04/28/2014 03:49 PM, Adam Jackson wrote:
On Mon, 2014-04-28 at 09:58 -0400, Casey Dahlin wrote:
On Mon, Apr 28, 2014 at 08:57:27AM -0400, Adam Jackson wrote:
On Sun, 2014-04-27 at 23:02 +0100, Andrew Price wrote:
On 24/04/14 15:13, Lennart Poettering wrote:
We probably should make setjmp()-freeness a requirement for all code included in Fedora.
Would it be worth the effort, and how feasible is it anyway?
I don't think it'd be worth the effort, and I think the burden of computing feasibility should rest with those who think it _is_ worth the effort.
Well, we could consider banning it from new packages and just let attrition take care of the rest.
We could. I still wouldn't consider that a productive use of time. It's a rare API that can't be misused, I'd much prefer if we approached code quality by _actually reading the code_ rather than deciding with grep what we will and won't accept.
I know that's a radical idea, that as packagers we ought actually to know the language of the code being packaged, but I think it has merit.
Indeed. setjmp has its uses; they're not very common, but it's not unreasonable for an upstream programmer to use setjmp.
Andrew.
On Mon, 28 Apr 2014, Adam Jackson wrote:
A completely arbitrary datapoint:
dmt:~% file /lib64/* | grep ELF.*shared | cut -f 1 -d : | xargs nm -aDu | grep -c setjmp 79
At a minimum you'd have to rewrite freetype, have fun with that.
I'm happy for libreswan/openswan to not use it, if someone wants to write a patch for the pam auth handler that does not need sigsetjmp()
Paul
On 04/28/2014 02:57 PM, Adam Jackson wrote:
A completely arbitrary datapoint:
dmt:~% file /lib64/* | grep ELF.*shared | cut -f 1 -d : | xargs nm -aDu | grep -c setjmp 79
Less arbitrary data point: 761 source packages in Fedora rawhide reference any of the setjmp, _setjmp, or __sigsetjmp ELF symbols (of 7154 source packages that define any ELF symbols).
2014-04-28 0:02 GMT+02:00 Andrew Price anprice@redhat.com:
On 24/04/14 15:13, Lennart Poettering wrote:
We probably should make setjmp()-freeness a requirement for all code included in Fedora.
Would it be worth the effort, and how feasible is it anyway?
Generally no. Been there, done that.
Avoiding setjmp() involves touching well over 75% lines of affected code to add explicit alternative return paths. The result might be cleaner but this is so radical a change that it is also very likely to introduce new bugs. As far as cleanups go, this is on the very end of the "you'd be crazy to do it in Fedora other than doing it upstream and rebasing" scale.
(OTOH if the code is using setjmp() *and* also using it incorrectly, there's no other practical thing to do than to do such a huge line-by-line rewrite.) Mirek
2014-04-27 19:02 GMT-03:00 Andrew Price anprice@redhat.com:
On 24/04/14 15:13, Lennart Poettering wrote:
We probably should make setjmp()-freeness a requirement for all code included in Fedora.
Would it be worth the effort, and how feasible is it anyway?
- Do we have any usage statistics?
- How often do we see bugs caused by bad uses of setjmp/longjmp?
- Is mitigation instead of blanket removal possible?
- How likely is it that /all/ setjmp/longjmp uses can be reasonably
replaced?
- Is there existing upstream momentum to move away from setjmp/longjmp?
(I'm not against the idea but I think it deserves further discussion.)
I think setjmp and longjmp should be treated as a warning, and replaced with sigsetjmp and siglongjmp, but not a fatal error, if I recall correctly, grub has its own setjmp/longjmp implementation. Probably should be a rpmlint warning, like the one of libraries that call exit.
Andy
Paulo
On Tue, Apr 29, 2014 at 12:08:11PM -0300, Paulo César Pereira de Andrade wrote:
2014-04-27 19:02 GMT-03:00 Andrew Price anprice@redhat.com:
On 24/04/14 15:13, Lennart Poettering wrote:
We probably should make setjmp()-freeness a requirement for all code included in Fedora.
Would it be worth the effort, and how feasible is it anyway?
- Do we have any usage statistics?
- How often do we see bugs caused by bad uses of setjmp/longjmp?
- Is mitigation instead of blanket removal possible?
- How likely is it that /all/ setjmp/longjmp uses can be reasonably
replaced?
- Is there existing upstream momentum to move away from setjmp/longjmp?
(I'm not against the idea but I think it deserves further discussion.)
I think setjmp and longjmp should be treated as a warning, and replaced with sigsetjmp and siglongjmp, but not a fatal error, if I recall correctly, grub has its own setjmp/longjmp implementation. Probably should be a rpmlint warning, like the one of libraries that call exit.
Or like the existing check on setuid order, etc.
But in order to be useful, we need a detailed reason on why it should be a warning, and what the packager should tell upstream. Even if I agree with Ajax about being able to read source code ( which I do, and which permitted to find security issues before it hit Fedora ), I also know not everybody is fluent in programming. So without any page that outline why it is a warning and that tell when it can be ignored, this will not be added to rpmlint.