Bug 1495181

I see:
 Jan Kurik 2017-09-25 08:26:39 EDT
Whiteboard: ChangeAcceptedF28, SystemWideChange

At what meeting was this change 'Accepted'?  a pointer to a Fedora entity issue tracker of mailing list archive, or minutes is requested

Certainly in the mailing lists, this question seems unanswered


Date: Wed, 13 Sep 2017 06:15:39
From: Neal Gompa <ngompa13>
Reply-To: Development discussions related to Fedora <devel.org>
To: Development discussions related to Fedora <devel.org>
Subject: f-dev] Re: F28 System Wide Change: Deprecate TCP wrappers
...


So, I'm a comaintainer of a package that uses libwrap and such
(stunnel), and I don't particularly want to lose the tcp_wrappers
support in it, because I use stunnel in containers to set up secure
tunnels across a number of systems. Unlike firewall rules (which apply
globally to the host), the hosts.deny rules apply only within the
container, which is the behavior I want.

Also, your recommended alternative of using tcpd doesn't work if the
package containing it is gone (tcp_wrappers).

======================

similarly, we use hostname based denials (against a DNS we control) to restrict access to some servers [every interior host is allocated by MAC address, and switch and VLAN filtering, and has a PTR and forward A record]

There is no way to attain this in the firewalld, nor in a tcpd without wrappers, of which I know

Thank you

-- Russ herrold

The Change has been approved by FESCo [1] on FESCo meeting [2].

[1] https://pagure.io/fesco/issue/1776
[2] https://meetbot.fedoraproject.org/teams/fesco/fesco.2017-09-22-16.00.log.html#l-369

Jan, thanks for the link for the minutes. It brings some more insights.

> Also, your recommended alternative of using tcpd doesn't work if the
package containing it is gone (tcp_wrappers).

It was not agreed that the package will be gone completely. It might continue living just without devel package to avoid building against it and allowing people like you to use tcpd if you really wish to.

I am still trying to figure out what will cause least pain and accommodate requirements from most of Fedora users. What we certainly do not want is to remove it only from part of the packages or break composes by retiring the package while there are others using it.

Could you consider updating all application systemd startup scripts to something like:

ExecStart=@-/etc/alternatives/tcpd /usr/sbin/sshd -i $OPTIONS $CRYPTO_POLICY

instead of

ExecStart=-/usr/sbin/sshd -i $OPTIONS $CRYPTO_POLICY</code>

and then having an alternatives mechanism to ship either tcpd from tcp_wrappers or a trivial just-exec-wrapper?

Alternatively maybe tcp wrapper like functionality should actually be implemented in systemd itself...

There's certainly a lot of things that can't be done with firewalls or eBPF filters (pretty much anything that requires DNS lookups)

Another benefit of tcp wrappers is all the configuration being in one place.

On 2018-Feb-20, we have reached the Fedora 28 Change Checkpoint: Completion deadline (testable).

At this point, all accepted changes should be substantially complete, and testable. Additionally, if a change is to be enabled by default, it must be enabled at Change Completion deadline as well.

Change tracking bug should be set to the MODIFIED state to indicate it achieved completeness.

Incomplete and non testable Changes will be reported to FESCo for 2018-Feb-23 meeting.

This bug appears to have been reported against 'rawhide' during the Fedora 28 development cycle.
Changing version to '28'.

Yes, this id done. The -devel subpackage was removed and the dependent packages that were not updated failed to rebuild during the mass rebuild. But the important tracked packages were updated properly.

On 2018-Mar-08 we reached the "Change Checkpoint: 100% Code Complete Deadline" milestone for Fedora 28 release. At this point all the Changes not at least in "ON_QA" state should be brought to FESCo for review. Please update the state of this bug to "ON_QA" if it is already 100% completed. Please let me know in case you have any trouble with the implementation and the Change needs any help or review.

Thanks, Jan

I think we must activate the contingency mechanism on this. There is still a bunch of packages which have the dependency (bugs in NEW state), and even if it would be possible to find manpower to update them, it would be against the update guidelines which discourage any major changes after beta. IMHO, the right solution is work on the remaining packages for rawhide / F29, and restore the -devel subpackage for now, i.e. revert [1].

[1] https://src.fedoraproject.org/rpms/tcp_wrappers/c/d6060d3aca06aa3c1b1398e82d1e712da456bdb4?branch=master

I'll reopen the FESCo ticket to discuss this at the next meeting.

Thank you for the note. It would be good to check what of the packages are really not fixed and which are just not updated. And which do not need the tcp_wrappers at all.

I believe this was properly announced to the owners of the affected packages and they had all the time to fix their dependency, given that the changes were very small.

I will check that also against the Fedora 28 repos and update the bugs. Just now, running the same query returns just a few packages:

$ dnf --releasever=28 repoquery --whatrequires 'libwrap.so.0()(64bit)'|grep x86_64
apcupsd-0:3.14.14-8.fc28.x86_64
apcupsd-cgi-0:3.14.14-8.fc28.x86_64
apcupsd-gui-0:3.14.14-8.fc28.x86_64
libyaz-0:5.14.11-9.fc28.x86_64
nrpe-0:3.2.1-1.fc28.x86_64
nut-0:2.7.4-13.fc28.x86_64
openhpi-subagent-0:2.3.4-33.fc27.x86_64
redir-0:2.2.1-18.fc27.x86_64
slapi-nis-0:0.56.2-1.fc28.x86_64
uwsgi-router-access-0:2.0.15-7.fc28.x86_64

From where:
 * apcupsd just needs a rebuild after net-snmp removed tcp_wrappers support
 * yaz needs to remove tcp_wrappers support (one build-requires, one configure line)
 * nrpe needs to remove tcp_wrappers support (build requires, configure should take care of missing library itself)
 * nut -- needs just a rebuild after removing tcp_wrappers from net-snmp
 * openhpi -- needs just a rebuild after removing tcp_wrappers from net-snmp
 * redir -- already removed tcp_wrappers in master, but did not merge+build F28 yet
 * slapdi -- already removed in F28, probably not yet in stable repositories
 * uwsgi -- the condition is written the other way round so the tcp_wrappers are needed only on F28+

I believe it make sense to discuss this with FESCO, but I don't think it makes sense to reintroduce the -devel subpackage. I will update also the dependent bugs to match the reality and to request missing actions from the maintainers.

>  * uwsgi -- the condition is written the other way round so the tcp_wrappers are needed only on F28+

I was probably reading the spec file wrongly. The reason why it is not in F28 is that it was built in master and F27, but not in F28 for whatever reason [1]. I will update also this bug with this information.

[1] https://koji.fedoraproject.org/koji/packageinfo?packageID=13358

Still reproducible 
[sumantro@localhost-live ~]$     dnf repoquery --whatrequires 'libwrap.so.0()(64bit)'|grep x86_64
                                                            
Fedora 28 - x86_64 - Test Updates               591 kB/s | 8.2 MB     00:14    
Fedora 28 - x86_64 - Updates                    766  B/s | 257  B     00:00    
Fedora 28 - x86_64                              1.0 MB/s |  60 MB     01:00    
Last metadata expiration check: 0:00:00 ago on Thu 22 Mar 2018 07:43:19 AM IST.
apcupsd-0:3.14.14-8.fc28.x86_64
apcupsd-cgi-0:3.14.14-8.fc28.x86_64
apcupsd-gui-0:3.14.14-8.fc28.x86_64
libyaz-0:5.14.11-9.fc28.x86_64
nrpe-0:3.2.1-1.fc28.x86_64
nut-0:2.7.4-13.fc28.x86_64
openhpi-subagent-0:2.3.4-33.fc27.x86_64
redir-0:2.2.1-18.fc27.x86_64
slapi-nis-0:0.56.2-1.fc28.x86_64
uwsgi-router-access-0:2.0.15-7.fc28.x86_64

I can confirm the same results as in comment 12. I have tested the Fedora Server, latest updates with updates-testing on.

openhpi-subagent-2.3.4-34.fc28 has been submitted as an update to Fedora 28. https://bodhi.fedoraproject.org/updates/FEDORA-2018-62792d21de

FYI: The test case from comment 12 is not ideal, afaics dnf repoquery will still show packages that require libwrap from stable even if there is a newer package in updates-testing that does not depend on libwrap. :-/

Unfortunately there are still bugs blocking this one which are in NEW state: 389-ds-base, uwsgi, nut. I just checked, and there are no updates for those three packages, so the bug status is accurate. Moving back to MODIFIED.

Till, thank you for the help with building and patching the missing packages. Zbigniew, thanks for filling the bug I forgot about.

Unfortunately, I don't have a better way to verify that it is fixed in some of the packages in the testing and that is the reason why I put there a manual comment what needs to be done with what package or if it is already fixed. Today run is still the same:

$ dnf --releasever=28 repoquery --whatrequires 'libwrap.so.0()(64bit)'|grep apcupsd-0:3.14.14-8.fc28.x86_64
apcupsd-cgi-0:3.14.14-8.fc28.x86_64
apcupsd-gui-0:3.14.14-8.fc28.x86_64
libyaz-0:5.14.11-9.fc28.x86_64
nrpe-0:3.2.1-1.fc28.x86_64
nut-0:2.7.4-13.fc28.x86_64
openhpi-subagent-0:2.3.4-33.fc27.x86_64
redir-0:2.2.1-18.fc27.x86_64
slapi-nis-0:0.56.2-1.fc28.x86_64
uwsgi-router-access-0:2.0.15-7.fc28.x86_64

I manually verified that all the following packages showing in the above result are fixed in latest build in updates testing:

 * apcupsd
   https://bodhi.fedoraproject.org/updates/FEDORA-2018-7c30f34b54
 * yaz
   https://bodhi.fedoraproject.org/updates/FEDORA-2018-694893ed80
 * nrpe
   https://bodhi.fedoraproject.org/updates/FEDORA-2018-c5d690d9a0
 * nut
   https://bodhi.fedoraproject.org/updates/FEDORA-2018-3d57f95deb
 * openhpi-subagent
   https://bodhi.fedoraproject.org/updates/FEDORA-2018-62792d21de
 * redir
   https://bodhi.fedoraproject.org/updates/FEDORA-2018-6155ae1482
 * slapi-nis
   https://bodhi.fedoraproject.org/updates/FEDORA-2018-fd4bdec6eb

From your list, there is:

 * 389-ds-base
   the bug is bogus now so I closed its bug to avoid the confusion (it was rebuilt and fixed ages ago, but the bug was not updated)

The last package is:

 * uwsgi
   failed to build on all recent attempts. The latest attempt was because of something was broken in rawhide?

Till, are you having a look into that, or should I investigate why it does not work and try to submit a PR?

Jakub, it would be great if you could look into uwsgi, here are the current build failures:
https://kojipkgs.fedoraproject.org//work/tasks/8025/26038025/build.log
https://koji.fedoraproject.org/koji/taskinfo?taskID=26038025
incompatible function types from 'PyObject * (*)(PyObject *, PyObject *, PyObject *)' {aka 'struct _object * (*)(struct _object *, struct _object *, struct _object *)'} to 'PyObject * (*)(PyObject *, PyObject *)' {aka 'struct _object * (*)(struct _object *, struct _object *)'} [-Wcast-function-type]
  {"send_to_spooler", (PyCFunction) py_uwsgi_send_spool, METH_KEYWORDS, ""},
                      ^
plugins/python/uwsgi_pymodule.c:2567:12: warning: cast between incompatible function types from 'PyObject * (*)(PyObject *, PyObject *, PyObject *)' {aka 'struct _object * (*)(struct _object *, struct _object *, struct _object *)'} to 'PyObject * (*)(PyObject *, PyObject *)' {aka 'struct _object * (*)(struct _object *, struct _object *)'} [-Wcast-function-type]
  {"spool", (PyCFunction) py_uwsgi_send_spool, METH_KEYWORDS, ""},
            ^
plugins/python/uwsgi_pymodule.c:2665:19: warning: cast between incompatible function types from 'PyObject * (*)(PyObject *, PyObject *, PyObject *)' {aka 'struct _object * (*)(struct _object *, struct _object *, struct _object *)'} to 'PyObject * (*)(PyObject *, PyObject *)' {aka 'struct _object * (*)(struct _object *, struct _object *)'} [-Wcast-function-type]
  {"mule_get_msg", (PyCFunction) py_uwsgi_mule_get_msg, METH_VARARGS|METH_KEYWORDS, ""},
                   ^
In file included from /usr/include/ruby.h:33,
                 from plugins/rack/uwsgi_rack.h:3,
                 from plugins/rack/rack_plugin.c:1:
plugins/rack/rack_plugin.c: In function 'uwsgi_ruby_exception_log':
plugins/rack/rack_plugin.c:117:14: error: call to 'rb_varargs_bad_length' declared with attribute error:  argument length doesn't match
  VALUE msg = rb_funcall(err, rb_intern("message"), 0, 0);
              ^~~~~~~~~~
plugins/rack/rack_plugin.c: In function 'uwsgi_ruby_exception_msg':
plugins/rack/rack_plugin.c:74:12: error: call to 'rb_varargs_bad_length' declared with attribute error:  argument length doesn't match
  VALUE e = rb_funcall(err, rb_intern("message"), 0, 0);

I removed the BR: on tcpwrapper for 389-ds-base but it does not build due to in unrelated error afaics:
https://koji.fedoraproject.org/koji/taskinfo?taskID=26039505
https://kojipkgs.fedoraproject.org//work/tasks/9505/26039505/build.log
libtool: link: gcc -O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -fexceptions -fstack-protector-strong -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -mcet -fcf-protection -Wl,-z -Wl,relro -Wl,-z -Wl,now -specs=/usr/lib/rpm/redhat/redhat-hardened-ld -o .libs/migratecred ldap/servers/slapd/tools/migratecred-migratecred.o  ./.libs/libslapd.so -L/usr/lib64 -lkrb5 -lk5crypto -lcom_err -lpcre -lsystemd /builddir/build/BUILD/389-ds-base-1.4.0.6/.libs/libsds.so -ltcmalloc -lpthread -lplc4 -lplds4 -lnspr4 -lssl3 -lnss3 -lsvrcore -lldap_r -llber -lsasl2 -Wl,-rpath -Wl,/usr/lib64/dirsrv
libtool: link: gcc -O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -fexceptions -fstack-protector-strong -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -mcet -fcf-protection -Wl,-z -Wl,relro -Wl,-z -Wl,now -specs=/usr/lib/rpm/redhat/redhat-hardened-ld -o .libs/mmldif ldap/servers/slapd/tools/mmldif-mmldif.o  ./.libs/libslapd.so -L/usr/lib64 -lldap_r -lkrb5 -lk5crypto -lcom_err -lpcre -lsystemd /builddir/build/BUILD/389-ds-base-1.4.0.6/.libs/libsds.so -ltcmalloc -lpthread -lplc4 -lplds4 -lnspr4 -lssl3 -lnss3 -lsvrcore -lldap -llber -lsasl2 -Wl,-rpath -Wl,/usr/lib64/dirsrv
libtool:   error: cannot find the library 'libldaputil.la' or unhandled argument 'libldaputil.la'
make[1]: *** [Makefile:6592: ns-slapd] Error 1
make[1]: *** Waiting for unfinished jobs....
libtool: link: ( cd ".libs" && rm -f "libaddn-plugin.la" && ln -s "../libaddn-plugin.la" "libaddn-plugin.la" )
libtool: link: (cd ".libs" && rm -f "libldaputil.so.0" && ln -s "libldaputil.so.0.0.0" "libldaputil.so.0")
libtool: link: (cd ".libs" && rm -f "libldaputil.so" && ln -s "libldaputil.so.0.0.0" "libldaputil.so")
libtool: link: ( cd ".libs" && rm -f "libldaputil.la" && ln -s "../libldaputil.la" "libldaputil.la" )
make[1]: Leaving directory '/builddir/build/BUILD/389-ds-base-1.4.0.6'
make: *** [Makefile:4417: all] Error 2

If you submit any PR, please ping me and I will merge them.

btw. regarding uwsgi, there is also uwsgi-2.0.17 available. Maybe it contains the necessary fix already.

openhpi-subagent-2.3.4-34.fc28 has been pushed to the Fedora 28 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2018-62792d21de

Till, I managed the uwsgi package to build with Fedora 28, but the rawhide still has some problems with gluster. There is PR and comment in the uwsgi bug #1518795.

Unfortunately I need to leave now, but in worst case, the Fedora 28 build should be possible now.

Awesome, thank you Jakub! I merged the PR (also in F28) and will create an F28 update. Then at least F28 will be clean and Rawhide can be fixed afterwards.

openhpi-subagent-2.3.4-34.fc28 has been pushed to the Fedora 28 stable repository. If problems still persist, please make note of it in this bug report.

Thanks for removing a very useful feature from Fedora!

Besides that, the migration document of 
https://fedoraproject.org/wiki/Changes/Deprecate_TCP_wrappers

does not work
# systemctl start sshd.socket
Job failed. See "journalctl -xe" for details.

# journalctl -xe
░░ Subject: A stop job for unit sshd.service has begun execution
░░ Defined-By: systemd
░░ Support: https://lists.freedesktop.org/mailman/listinfo/systemd-devel
░░ 
░░ A stop job for unit sshd.service has begun execution.
░░ 
░░ The job identifier is 11033.
Apr 26 09:23:31 tk-laptop systemd[1]: sshd.service: Succeeded.
░░ Subject: Unit succeeded
░░ Defined-By: systemd
░░ Support: https://lists.freedesktop.org/mailman/listinfo/systemd-devel
░░ 
░░ The unit sshd.service has successfully entered the 'dead' state.
Apr 26 09:23:31 tk-laptop systemd[1]: Stopped OpenSSH server daemon.
░░ Subject: A stop job for unit sshd.service has finished
░░ Defined-By: systemd
░░ Support: https://lists.freedesktop.org/mailman/listinfo/systemd-devel
░░ 
░░ A stop job for unit sshd.service has finished.
░░ 
░░ The job identifier is 11033 and the job result is done.
Apr 26 09:23:31 tk-laptop systemd[1]: Stopped target sshd-keygen.target.
░░ Subject: A stop job for unit sshd-keygen.target has finished
░░ Defined-By: systemd
░░ Support: https://lists.freedesktop.org/mailman/listinfo/systemd-devel
░░ 
░░ A stop job for unit sshd-keygen.target has finished.
░░ 
░░ The job identifier is 11034 and the job result is done.