6:58 a.m.
Hello Fedora devels and users,
more than three years ago, the same topic started discussion if we want
this package in Fedora or not and how [1]. The discussion resulted
mostly in flames and in the removal of the dependency on tcp_wrappers
from systemd. But it was quite agreed that it is considered as a
security layer for some users, if they use it correctly, or something
that is or should be replaced by firewalls.
So can we discuss it now once more without the affiliation to systemd?
The fact is that we still do not have any other replacement except
firewalls. But do we need one?
The complete removal of the package is probably not a wise step, even
though we can not find tcp_wrappers in recent SuSE anymore [2]. It is
still available in Arch [3] without other tools depending on it. To be
fair, Debian [4] is still building tools (for example openssh) with a
build-time support for it.
My primary concern is OpenSSH, which upstream dropped support for
tcp_wrappers three years ago (late 2014) [5] and since then we are
maintaining one more downstream patch. But this effort should be
coordinated among other components to simplify the transition for users
who insist on using it (using tcpd).
Removing the dependency will also allow us to trim the default
install for few more Kb.
If there will be no significant drawbacks, I will progress with filling
a system wide change for Fedora 28 and I will pull the maintainers of
other tolls using libwrap into the round and discussion.
[1] https://lists.fedoraproject.org/pipermail/devel/2014-March/196913.h
tml
[2] https://www.rpmfind.net/linux/rpm2html/search.php?query=tcpd&submit
=Search+...&system=&arch=
[3] https://www.archlinux.org/packages/community/x86_64/tcp-wrappers/
[4] https://packages.debian.org/sid/openssh-server
[5] http://www.openssh.com/txt/release-6.7
Thank you for comments and constructive ideas.
Regards,
--
Jakub Jelen
Software Engineer
Security Technologies
Red Hat, Inc.
4:37 a.m.
On Tue, Aug 15, 2017 at 1:58 PM, Jakub Jelen <jjelen(a)redhat.com> wrote:
So can we discuss it now once more without the affiliation to systemd?
The fact is that we still do not have any other replacement except
firewalls. But do we need one?
IIRC, in the past discussion there was quite a lot of people arguing
that we actually need one. I personally don't think we as a
distribution need a drop-in replacement. However, what we possibly
need, is a migration path for already deployed systems using
tcp_wrappers. Just dropping tcp_wrappers and potentially leaving
deployed services completely open would very irresponsible.
Also we should consider an impact this change will have on our
downstreams focusing on enterprise use-cases (CentOS, RHEL). I recon
that "splash damage" potentially caused by this change will be bigger
there than in Fedora itself.
Michal
4:44 a.m.
On 08/16/2017 11:37 AM, Michal Sekletar wrote:
On Tue, Aug 15, 2017 at 1:58 PM, Jakub Jelen
<jjelen(a)redhat.com> wrote:
>
> So can we discuss it now once more without the affiliation to systemd?
> The fact is that we still do not have any other replacement except
> firewalls. But do we need one?
>
IIRC, in the past discussion there was quite a lot of people arguing
that we actually need one. I personally don't think we as a
distribution need a drop-in replacement. However, what we possibly
need, is a migration path for already deployed systems using
tcp_wrappers. Just dropping tcp_wrappers and potentially leaving
deployed services completely open would very irresponsible.
Also we should consider an impact this change will have on our
downstreams focusing on enterprise use-cases (CentOS, RHEL). I recon
that "splash damage" potentially caused by this change will be bigger
there than in Fedora itself.
On the other hand shipping downstream openssh patch adding this support
when there is already similar functionality present in upstream via the
Match directive in sshd_config is something I would definitely not vote for.
Tomas
11:10 a.m.
On 16 August 2017 at 05:44, Tomas Mraz <tmraz(a)redhat.com> wrote:
On 08/16/2017 11:37 AM, Michal Sekletar wrote:
> On Tue, Aug 15, 2017 at 1:58 PM, Jakub Jelen <jjelen(a)redhat.com> wrote:
>
>>
>> So can we discuss it now once more without the affiliation to systemd?
>> The fact is that we still do not have any other replacement except
>> firewalls. But do we need one?
>>
>
> IIRC, in the past discussion there was quite a lot of people arguing
> that we actually need one. I personally don't think we as a
> distribution need a drop-in replacement. However, what we possibly
> need, is a migration path for already deployed systems using
> tcp_wrappers. Just dropping tcp_wrappers and potentially leaving
> deployed services completely open would very irresponsible.
>
> Also we should consider an impact this change will have on our
> downstreams focusing on enterprise use-cases (CentOS, RHEL). I recon
> that "splash damage" potentially caused by this change will be bigger
> there than in Fedora itself.
On the other hand shipping downstream openssh patch adding this support
when there is already similar functionality present in upstream via the
Match directive in sshd_config is something I would definitely not vote
for.
The main purpose of tcp_wrappers is to allow a 'live' control mechanism to
an op level person/program who may not be able to change configuration
files without going through change control systems or restart services (for
similar reasons).
In various places, changing a startup/shutdown program requires going
through all kinds of extra hassles. So having a layer where the 'local'
admin can quickly 'stop' some resource usage is required. The tcp_wrappers
was the mechanism to do this. This meant that openssh/postfix/etc did not
need to be restarted to get the new ips to allow or disallow. A program
could go through logs and add/remove hosts to a file without altering other
files and thus could be apparmor/selinux policy limited for further
protections.
If there is a way to have systemd read from a 'central' file to allow/deny
ips without requiring a systemctl reload/restart of all the services that
would be useful to know and would be the way to call it a 'replacement' of
the original functionality. Then any .service file could just say it is
looking at that file for appropriate matches and those that don't need it
don't.
Tomas
_______________________________________________
devel mailing list -- devel(a)lists.fedoraproject.org
To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
--
Stephen J Smoogen.
4:33 a.m.
On Wed, 2017-08-16 at 12:10 -0400, Stephen John Smoogen wrote:
On 16 August 2017 at 05:44, Tomas Mraz <tmraz(a)redhat.com>
wrote:
> On 08/16/2017 11:37 AM, Michal Sekletar wrote:
> > On Tue, Aug 15, 2017 at 1:58 PM, Jakub Jelen <jjelen(a)redhat.com>
> > wrote:
> >
> > >
> > > So can we discuss it now once more without the affiliation to
> > > systemd?
> > > The fact is that we still do not have any other replacement
> > > except
> > > firewalls. But do we need one?
> > >
> >
> > IIRC, in the past discussion there was quite a lot of people
> > arguing
> > that we actually need one. I personally don't think we as a
> > distribution need a drop-in replacement. However, what we
> > possibly
> > need, is a migration path for already deployed systems using
> > tcp_wrappers. Just dropping tcp_wrappers and potentially leaving
> > deployed services completely open would very irresponsible.
> >
> > Also we should consider an impact this change will have on our
> > downstreams focusing on enterprise use-cases (CentOS, RHEL). I
> > recon
> > that "splash damage" potentially caused by this change will be
> > bigger
> > there than in Fedora itself.
>
> On the other hand shipping downstream openssh patch adding this
> support
> when there is already similar functionality present in upstream via
> the
> Match directive in sshd_config is something I would definitely not
> vote
> for.
The main purpose of tcp_wrappers is to allow a 'live' control
mechanism to
an op level person/program who may not be able to change
configuration
files without going through change control systems or restart
services (for
similar reasons).
In various places, changing a startup/shutdown program requires going
through all kinds of extra hassles. So having a layer where the
'local'
admin can quickly 'stop' some resource usage is required. The
tcp_wrappers
was the mechanism to do this. This meant that openssh/postfix/etc did
not
need to be restarted to get the new ips to allow or disallow. A
program
could go through logs and add/remove hosts to a file without altering
other
files and thus could be apparmor/selinux policy limited for further
protections.
If there is a way to have systemd read from a 'central' file to
allow/deny
ips without requiring a systemctl reload/restart of all the services
that
would be useful to know and would be the way to call it a
'replacement' of
the original functionality. Then any .service file could just say it
is
looking at that file for appropriate matches and those that don't
need it
don't.
AFAIK, that was the feature that was removed from systemd in 2014. It
can not work for services (they handle the connections on their own),
but it can simply work with systemd sockets (and instanced services).
And the same way it worked for sockets, it will work in future using
tcpd by replacing
ExecStart=-/usr/sbin/sshd -i $OPTIONS
with
ExecStart=@-/usr/sbin/tcpd /usr/sbin/sshd -i $OPTIONS
in /etc/systemd/system/sshd@.service (for SSHD example). Source [1].
It needs some tweaks to SELinux policy (I am having a look into that),
but there is a way for these who need it.
Also using sockets will allow you that every service instance is
reading a fresh configuration (in SSHD case).
[1] https://lists.freedesktop.org/archives/systemd-devel/2014-April/018
793.html
Regards,
--
Jakub Jelen
Software Engineer
Security Technologies
Red Hat, Inc.
10:42 a.m.
On Tue, 2017-08-15 at 13:58 +0200, Jakub Jelen wrote:
Hello Fedora devels and users,
more than three years ago, the same topic started discussion if we
want
this package in Fedora or not and how [1]. The discussion resulted
mostly in flames and in the removal of the dependency on tcp_wrappers
from systemd. But it was quite agreed that it is considered as a
security layer for some users, if they use it correctly, or something
that is or should be replaced by firewalls.
So can we discuss it now once more without the affiliation to
systemd?
The fact is that we still do not have any other replacement except
firewalls. But do we need one?
The complete removal of the package is probably not a wise step, even
though we can not find tcp_wrappers in recent SuSE anymore [2]. It is
still available in Arch [3] without other tools depending on it. To
be
fair, Debian [4] is still building tools (for example openssh) with a
build-time support for it.
My primary concern is OpenSSH, which upstream dropped support for
tcp_wrappers three years ago (late 2014) [5] and since then we are
maintaining one more downstream patch. But this effort should be
coordinated among other components to simplify the transition for
users
who insist on using it (using tcpd).
Removing the dependency will also allow us to trim the default
install for few more Kb.
If there will be no significant drawbacks, I will progress with
filling
a system wide change for Fedora 28 and I will pull the maintainers of
other tolls using libwrap into the round and discussion.
Hello,
In Fedora 26, there is over 50 packages using tcp_wrappers as a build-
time dependency:
$ dnf repoquery --whatrequires 'libwrap.so.0()(64bit)'|grep x86_64
389-ds-base-snmp-0:1.3.6.6-2.fc26.x86_64 rmeggins
aeskulap-0:0.2.2-0.27.beta1.fc26.x86_64 jenslody
apcupsd-0:3.14.14-5.fc26.x86_64 tibbs
apcupsd-cgi-0:3.14.14-5.fc26.x86_64
apcupsd-gui-0:3.14.14-5.fc26.x86_64
apt-cacher-ng-0:0.9.0-3.fc26.x86_64 kenjiro
audit-0:2.7.7-1.fc26.x86_64 sgrubb
bacula-client-0:7.4.7-1.fc26.x86_64 slaanesh
bacula-director-0:7.4.7-1.fc26.x86_64
bacula-libs-0:7.4.7-1.fc26.x86_64
bacula-storage-0:7.4.7-1.fc26.x86_64
bacula2-client-0:2.4.4-24.fc26.x86_64 limb
conserver-0:8.2.1-3.fc24.x86_64 jkastner
ctk-devel-0:0.1-0.2.20151015gitbdc8cac.fc26.x86_64 bizdelnick
ctk-dicom-0:0.1-0.2.20151015gitbdc8cac.fc26.x86_64
cyrus-imapd-0:3.0.1-7.fc26.x86_64 landgraf
dcmtk-0:3.6.1-4.fc24.x86_64 ignatenkobrain
dovecot-1:2.2.31-3.fc26.x86_64 mhlavink
exim-0:4.89-1.fc26.x86_64 dwmw2
flow-tools-0:0.68.5.1-18.fc26.x86_64 stingray
foghorn-0:0.1.6-12.fc26.x86_64 rohara
gsi-openssh-server-0:7.5p1-1.fc26.x86_64 ellert
libvirt-snmp-0:0.0.3-7.fc24.x86_64 mprivozn
libyaz-0:5.14.11-6.fc26.x86_64 guidograzioli
lldpd-0:0.9.7-5.fc26.x86_64 jhogarth
net-snmp-1:5.7.3-15.fc26.x86_64 jsafrane
net-snmp-agent-libs-1:5.7.3-15.fc26.x86_64
nfs-utils-1:2.1.1-5.rc4.fc26.x86_64 steved
ngircd-0:24-2.fc26.x86_64 ixs
nrpe-0:3.0.1-4.fc26.x86_64 smooge
nut-0:2.7.4-7.fc26.x86_64 mhlavink
ocserv-0:0.11.8-1.fc26.x86_64 nmav
openhpi-subagent-0:2.3.4-28.fc26.x86_64 sharkcz
openldap-servers-0:2.4.44-10.fc26.x86_64 mhonek
opensips-snmpstats-0:2.2.3-1.fc26.x86_64 ivaxer
openssh-server-0:7.5p1-2.fc26.x86_64 jjelen
pptpd-0:1.4.0-11.fc26.x86_64 jskarvad
prelude-manager-0:3.1.0-2.fc26.x86_64 totol
proftpd-0:1.3.6-1.fc26.x86_64 itamarjp
ptpd-0:2.3.1-4.fc24.x86_64 pbrobinson
pulseaudio-libs-0:10.0-4.fc26.x86_64 lennart
quagga-0:1.1.1-2.fc26.x86_64 mruprich
quota-rpc-1:4.03-8.fc26.x86_64 ppisar
redir-0:2.2.1-16.fc26.x86_64 itamarjp
rpcbind-0:0.2.4-7.rc2.fc26.x86_64 steved
rwhoisd-0:1.5.9.6-6.fc26.x86_64 ppisar
sendmail-0:8.15.2-14.fc26.x86_64 jskarvad
slapi-nis-0:0.56.1-2.fc26.x86_64 abbra
sslh-0:1.18-2.fc26.x86_64 jhogarth
stunnel-0:5.41-1.fc26.x86_64 tmraz
syslog-ng-0:3.9.1-1.fc26.x86_64 marcusk
tcp_wrappers-devel-0:7.6-85.fc26.x86_64 jjelen
tftp-server-0:5.2-20.fc26.x86_64 jsynacek
up-imapproxy-0:1.2.8-0.7.20130726svn14389.fc24.x86_64 cmadams
uwsgi-router-access-0:2.0.15-1.fc26.x86_64 kad
vsftpd-0:3.0.3-5.fc26.x86_64 msehnout
xinetd-2:2.3.15-18.fc26.x86_64 jsynacek
I added the main contacts on these packages to the bcc to let them
express their opinions on this proposal and usefulness of tcp_wrappers
in case of their package and their upstream community.
This is not a call for immediate action, but more a discussion, if
there is a way and will to get rid of this dependency.
As already mentioned, I would like to see that go in one go (eg. Fedora
28) so anyone using them currently, can step back to tcpd or swat to
firewall at once for all the services, if possible.
Thanks,
Jakub
>
>
> [1] https://lists.fedoraproject.org/pipermail/devel/2014-March/196913
> .h
> tml
> [2] https://www.rpmfind.net/linux/rpm2html/search.php?query=tcpd&subm
> it
> =Search+...&system=&arch=
> [3] https://www.archlinux.org/packages/community/x86_64/tcp-wrappers/
> [4] https://packages.debian.org/sid/openssh-server
> [5] http://www.openssh.com/txt/release-6.7
>
>
> Thank you for comments and constructive ideas.
> Regards,
> --
> Jakub Jelen
11:43 a.m.
On Fri, 18 Aug 2017 17:42:21 +0200
Jakub Jelen <jjelen(a)redhat.com> wrote:
On Tue, 2017-08-15 at 13:58 +0200, Jakub Jelen wrote:
> Hello Fedora devels and users,
>
> more than three years ago, the same topic started discussion if we
> want
> this package in Fedora or not and how [1]. The discussion resulted
> mostly in flames and in the removal of the dependency on
> tcp_wrappers from systemd. But it was quite agreed that it is
> considered as a security layer for some users, if they use it
> correctly, or something that is or should be replaced by firewalls.
>
> So can we discuss it now once more without the affiliation to
> systemd?
> The fact is that we still do not have any other replacement except
> firewalls. But do we need one?
>
> The complete removal of the package is probably not a wise step,
> even though we can not find tcp_wrappers in recent SuSE anymore
> [2]. It is still available in Arch [3] without other tools
> depending on it. To be
> fair, Debian [4] is still building tools (for example openssh) with
> a build-time support for it.
>
> My primary concern is OpenSSH, which upstream dropped support for
> tcp_wrappers three years ago (late 2014) [5] and since then we are
> maintaining one more downstream patch. But this effort should be
> coordinated among other components to simplify the transition for
> users
> who insist on using it (using tcpd).
>
> Removing the dependency will also allow us to trim the default
> install for few more Kb.
>
> If there will be no significant drawbacks, I will progress with
> filling
> a system wide change for Fedora 28 and I will pull the maintainers
> of other tolls using libwrap into the round and discussion.
Hello,
In Fedora 26, there is over 50 packages using tcp_wrappers as a build-
time dependency:
the query shows packages with run-time (not build-time) dependencies,
in some cases it's an indirect dependency, so the actual list is shorter
$ dnf repoquery --whatrequires 'libwrap.so.0()(64bit)'|grep
x86_64
389-ds-base-snmp-0:1.3.6.6-2.fc26.x86_64 rmeggins
aeskulap-0:0.2.2-0.27.beta1.fc26.x86_64 jenslody
apcupsd-0:3.14.14-5.fc26.x86_64 tibbs
apcupsd-cgi-0:3.14.14-5.fc26.x86_64
apcupsd-gui-0:3.14.14-5.fc26.x86_64
apt-cacher-ng-0:0.9.0-3.fc26.x86_64 kenjiro
audit-0:2.7.7-1.fc26.x86_64 sgrubb
bacula-client-0:7.4.7-1.fc26.x86_64 slaanesh
bacula-director-0:7.4.7-1.fc26.x86_64
bacula-libs-0:7.4.7-1.fc26.x86_64
bacula-storage-0:7.4.7-1.fc26.x86_64
bacula2-client-0:2.4.4-24.fc26.x86_64 limb
conserver-0:8.2.1-3.fc24.x86_64 jkastner
ctk-devel-0:0.1-0.2.20151015gitbdc8cac.fc26.x86_64 bizdelnick
ctk-dicom-0:0.1-0.2.20151015gitbdc8cac.fc26.x86_64
cyrus-imapd-0:3.0.1-7.fc26.x86_64 landgraf
dcmtk-0:3.6.1-4.fc24.x86_64 ignatenkobrain
dovecot-1:2.2.31-3.fc26.x86_64 mhlavink
exim-0:4.89-1.fc26.x86_64 dwmw2
flow-tools-0:0.68.5.1-18.fc26.x86_64 stingray
foghorn-0:0.1.6-12.fc26.x86_64 rohara
gsi-openssh-server-0:7.5p1-1.fc26.x86_64 ellert
libvirt-snmp-0:0.0.3-7.fc24.x86_64 mprivozn
libyaz-0:5.14.11-6.fc26.x86_64 guidograzioli
lldpd-0:0.9.7-5.fc26.x86_64 jhogarth
net-snmp-1:5.7.3-15.fc26.x86_64 jsafrane
net-snmp-agent-libs-1:5.7.3-15.fc26.x86_64
nfs-utils-1:2.1.1-5.rc4.fc26.x86_64 steved
ngircd-0:24-2.fc26.x86_64 ixs
nrpe-0:3.0.1-4.fc26.x86_64 smooge
nut-0:2.7.4-7.fc26.x86_64 mhlavink
ocserv-0:0.11.8-1.fc26.x86_64 nmav
openhpi-subagent-0:2.3.4-28.fc26.x86_64 sharkcz
openldap-servers-0:2.4.44-10.fc26.x86_64 mhonek
opensips-snmpstats-0:2.2.3-1.fc26.x86_64 ivaxer
openssh-server-0:7.5p1-2.fc26.x86_64 jjelen
pptpd-0:1.4.0-11.fc26.x86_64 jskarvad
prelude-manager-0:3.1.0-2.fc26.x86_64 totol
proftpd-0:1.3.6-1.fc26.x86_64 itamarjp
ptpd-0:2.3.1-4.fc24.x86_64 pbrobinson
pulseaudio-libs-0:10.0-4.fc26.x86_64 lennart
quagga-0:1.1.1-2.fc26.x86_64 mruprich
quota-rpc-1:4.03-8.fc26.x86_64 ppisar
redir-0:2.2.1-16.fc26.x86_64 itamarjp
rpcbind-0:0.2.4-7.rc2.fc26.x86_64 steved
rwhoisd-0:1.5.9.6-6.fc26.x86_64 ppisar
sendmail-0:8.15.2-14.fc26.x86_64 jskarvad
slapi-nis-0:0.56.1-2.fc26.x86_64 abbra
sslh-0:1.18-2.fc26.x86_64 jhogarth
stunnel-0:5.41-1.fc26.x86_64 tmraz
syslog-ng-0:3.9.1-1.fc26.x86_64 marcusk
tcp_wrappers-devel-0:7.6-85.fc26.x86_64 jjelen
tftp-server-0:5.2-20.fc26.x86_64 jsynacek
up-imapproxy-0:1.2.8-0.7.20130726svn14389.fc24.x86_64 cmadams
uwsgi-router-access-0:2.0.15-1.fc26.x86_64 kad
vsftpd-0:3.0.3-5.fc26.x86_64 msehnout
xinetd-2:2.3.15-18.fc26.x86_64 jsynacek
I added the main contacts on these packages to the bcc to let them
express their opinions on this proposal and usefulness of tcp_wrappers
in case of their package and their upstream community.
This is not a call for immediate action, but more a discussion, if
there is a way and will to get rid of this dependency.
As already mentioned, I would like to see that go in one go (eg.
Fedora
28) so anyone using them currently, can step back to tcpd or swat to
firewall at once for all the services, if possible.
Dan
1:15 p.m.
For the record, denyhosts currently relies upon the tcp_wrappers
functionality in openssh to function. While it's possible to make it
manipulate the firewall as well, the whole situation is kind of a mess.
(Does it talk to firewalld? What if you're not running firewalld?)
Sadly I know how terrible tcp_wrappers is and so I know it needs to go
away. It's just unfortunate that there's no replacement for it besides
firewalling, and dealing with the firewall is unfortunately so
complicated.
So that's three of my packages that use tcp_wrappers in some way
(denyhosts, apcupsd and cyrus-imapd) though I suspect two of those just
need the build dependencies dropped.
- J<
5:29 p.m.
On Fri, 18 Aug 2017, Jason L Tibbitts III wrote:
Sadly I know how terrible tcp_wrappers is and so I know it needs to
go
away.
just because crows trying to protect their young will 'mob' a
hawk hunting to feed her young does not make the hawk
terrible; latest is not always greatest
I found the ranting toward wrappers unconvincing years ago -
- I remain unconvinced that it is terrible code
It's just unfortunate that there's no replacement for it
besides
firewalling, and dealing with the firewall is unfortunately so
complicated.
wrappers will invoke the resolver, and do PTR lookups, and so
can do:
- hostname based,
- domain related, and
- absent DNS information based blocking
I know of no way to do these tasks with the 'firewalld' code
-- Russ herrold
3:21 a.m.
On Fri, 2017-08-18 at 13:15 -0500, Jason L Tibbitts III wrote:
For the record, denyhosts currently relies upon the tcp_wrappers
functionality in openssh to function. While it's possible to make it
manipulate the firewall as well, the whole situation is kind of a
mess.
(Does it talk to firewalld? What if you're not running firewalld?)
Unfortunately this is not as straightforward as it could be.
Checking how Archlinux does it now, they probably go without denyhosts.
There is a also a tool sshguard [1], which does quite much the same as
fail2ban using configurable backend (firewalld, iptables, ...).
The denyhosts got last update also 10 years ago [2] and we already have
quite much 2 alternatives that can do the same using firewalls, so it
might be also a time to go for denyhosts. Or not, but clearly document
that OpenSSH will not be using hosts.deny anymore.
Sadly I know how terrible tcp_wrappers is and so I know it needs to
go
away. It's just unfortunate that there's no replacement for it
besides
firewalling, and dealing with the firewall is unfortunately so
complicated.
So that's three of my packages that use tcp_wrappers in some way
(denyhosts, apcupsd and cyrus-imapd) though I suspect two of those
just
need the build dependencies dropped.
That would be great if you could review the dependencies if it is used
and drop the bogus dependencies.
[1] https://wiki.archlinux.org/index.php/sshguard
[2] https://sourceforge.net/projects/denyhosts/files/
Thanks,
--
Jakub Jelen
Software Engineer
Security Technologies
Red Hat, Inc.
9:56 a.m.
>>>> "JJ" == Jakub Jelen
<jjelen(a)redhat.com> writes:
JJ> The denyhosts got last update also 10 years ago [2] and we already
JJ> have quite much 2 alternatives that can do the same using firewalls,
JJ> so it might be also a time to go for denyhosts. Or not, but clearly
JJ> document that OpenSSH will not be using hosts.deny anymore.
The last denyhosts release was not much over two years ago, actually.
https://github.com/denyhosts/denyhosts
I am nominally active with denyhosts upstream, though I just don't have
the time to do the things I really want to do (like fix my support for
the systemd journal or get firewalld support merged).
JJ> That would be great if you could review the dependencies if it is
JJ> used and drop the bogus dependencies.
I can verify that the dependencies are real. There's nothing bogus
about them; the functionality works. But if course if tcp_wrappers is
really to be retired then they will need to be rebuilt without it.
- J<
3:30 p.m.
On ma, 21 elo 2017, Jason L Tibbitts III wrote:
>>>>> "JJ" == Jakub Jelen
<jjelen(a)redhat.com> writes:
JJ> The denyhosts got last update also 10 years ago [2] and we already
JJ> have quite much 2 alternatives that can do the same using firewalls,
JJ> so it might be also a time to go for denyhosts. Or not, but clearly
JJ> document that OpenSSH will not be using hosts.deny anymore.
The last denyhosts release was not much over two years ago, actually.
https://github.com/denyhosts/denyhosts
I am nominally active with denyhosts upstream, though I just don't have
the time to do the things I really want to do (like fix my support for
the systemd journal or get firewalld support merged).
JJ> That would be great if you could review the dependencies if it is
JJ> used and drop the bogus dependencies.
I can verify that the dependencies are real. There's nothing bogus
about them; the functionality works. But if course if tcp_wrappers is
really to be retired then they will need to be rebuilt without it.
For example,
slapi-nis has tcp_wrappers support built in. It can be
compiled out, all we would lose is NIS plugin not rejecting access to
NIS maps from clients that were defined in hosts.deny. Whether somebody
relies on this functionality or not, I'm not aware -- at least, I
haven't seen any bugs related to that within the FreeIPA NIS integration
context for last six or so years.
--
/ Alexander Bokovoy
2115
days inactive
2121
days old
11 comments
8 participants
participants (8)
-
Alexander Bokovoy -
Dan Horák -
Jakub Jelen -
Jason L Tibbitts III -
Michal Sekletar -
R P Herrold -
Stephen John Smoogen -
Tomas Mraz