Bug 1542361

Should have done this before reporting here:

The same happens for the upstream version 5.44 (but not for 5.43!), so it's not Fedora specific. The changelog tipped me off:

 > https://www.stunnel.org/sdf_ChangeLog.html
 > Bugfixes
 >   Default accept address restored to INADDR_ANY. 


The diff between these two version was small enough and after a bit of searching....with the following fix applied to 5.44, stunnel is able to bind to localhost again:


--- src/options.c.orig  2017-11-14 23:06:12.000000000 -0800
+++ src/options.c       2018-02-06 00:01:58.892498016 -0800
@@ -1151,7 +1151,7 @@ NOEXPORT char *parse_service_option(CMD
     /* accept */
     switch(cmd) {
     case CMD_BEGIN:
-        addrlist_clear(&section->local_addr, 1);
+        addrlist_clear(&section->local_addr, 0);
         break;
     case CMD_EXEC:
         if(strcasecmp(opt, "accept"))



== Workaround: use a numeric address for localhost ("127.0.0.1" or "::1" will do) in the 
   configuration file to have stunnel-5.44 bind to localhost:


$ grep  ^accept stunnel.test 
accept          = ::1:12345

$ /usr/bin/stunnel stunnel.test 
2018.02.06 00:13:20 LOG5[ui]: stunnel 5.44 on x86_64-redhat-linux-gnu platform
2018.02.06 00:13:20 LOG5[ui]: Compiled/running with OpenSSL 1.1.0g-fips  2 Nov 2017
2018.02.06 00:13:20 LOG5[ui]: Threading:PTHREAD Sockets:POLL,IPv6 TLS:ENGINE,FIPS,OCSP,PSK,SNI Auth:LIBWRAP
2018.02.06 00:13:20 LOG5[ui]: Reading configuration from file /home/christian/stunnel.test
2018.02.06 00:13:20 LOG5[ui]: UTF-8 byte order mark not detected
2018.02.06 00:13:20 LOG5[ui]: FIPS mode disabled
2018.02.06 00:13:20 LOG6[ui]: Initializing service [test]
2018.02.06 00:13:20 LOG4[ui]: Service [test] needs authentication to prevent MITM attacks
2018.02.06 00:13:20 LOG5[ui]: Configuration successful


The downside with this workaround is, that the client port (:12345) can now only be reached with either the configured IPv4 or IPv6 localhost address, but not both. With stunnel-5.43 and "accept=localhost:12345", it would serve both 127.0.0.1 and ::1.

Created attachment 1391876 [details]
allow stunnel to bind to localhost again

Would you be able to report the issue on the upstream mailing list?
https://www.stunnel.org/cgi-bin/mailman/listinfo/stunnel-users

Yeah, good idea, should've done this from the start, sorry for the noise:
https://www.stunnel.org/pipermail/stunnel-users/2018-February/005935.html

The issue has been fixed with stunnel-5.45b2, which is available from the stunnel website. I tried to "cherry-pick" the relevant changes and attached it to this bug, or one could wait until 5.45 is released, or just use the beta version :-)

Created attachment 1395772 [details]
diff to stunnel-5.44 with only the changes that should fix this particular issue.

stunnel-5.44-5.fc27 has been submitted as an update to Fedora 27. https://bodhi.fedoraproject.org/updates/FEDORA-2018-6d8f240360

stunnel-5.44-5.fc26 has been submitted as an update to Fedora 26. https://bodhi.fedoraproject.org/updates/FEDORA-2018-37a01354b4

stunnel-5.44-5.fc26 has been pushed to the Fedora 26 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-37a01354b4

stunnel-5.44-5.fc27 has been pushed to the Fedora 27 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-6d8f240360

Yes, this fixes this bug - thanks! (Also: is it preferred for the reporter to state this in this bug report or is it sufficient/preferred to do so on Bodhi? The latter may produce less emails to the subscribers to this bug, I guess)

Bodhi should be sufficient.

stunnel-5.44-5.fc26 has been pushed to the Fedora 26 stable repository. If problems still persist, please make note of it in this bug report.

stunnel-5.44-5.fc27 has been pushed to the Fedora 27 stable repository. If problems still persist, please make note of it in this bug report.

Upstream recently released version 5.45 which includes this fix. But then shortly after that they released version 5.46 which contains this in the changelog: "Default accept address restored to INADDR_ANY". Christian, could you please verify that the version 5.46 does not break this again?

Here is a scratch build to test:
https://koji.fedoraproject.org/koji/taskinfo?taskID=27274049

My testing with the configuration from the bug description works fine, I just want to be sure we do not regress.

I did not have a very exotic stunnel configuration, so I tested the configuration file that I was initially using, basically the stunnel.test in comment 0.


* stunnel-5.43 still works with that config.
* stunnel-5.44 (unfixed) fails, as reported.
* stunnel-5.44-5.fc28.x86_64 works.
* stunnel 5.46 (vanilla) works.
* stunnel-5.46-1.fc27 works too:


$ wget https://kojipkgs.fedoraproject.org//work/tasks/4052/27274052/stunnel-5.46-1.fc27.x86_64.rpm
$ rpm2cpio stunnel-5.46-1.fc27.x86_64.rpm | cpio -idv

$ LD_LIBRARY_PATH=./usr/lib64/stunnel ./usr/bin/stunnel stunnel.test 
2018.05.29 21:15:27 LOG5[ui]: stunnel 5.46 on x86_64-redhat-linux-gnu platform
2018.05.29 21:15:27 LOG5[ui]: Compiled/running with OpenSSL 1.1.0h-fips  27 Mar 2018
2018.05.29 21:15:27 LOG5[ui]: Threading:PTHREAD Sockets:POLL,IPv6 TLS:ENGINE,FIPS,OCSP,PSK,SNI Auth:LIBWRAP
2018.05.29 21:15:27 LOG5[ui]: Reading configuration from file /home/christian/s/stunnel.test
2018.05.29 21:15:27 LOG5[ui]: UTF-8 byte order mark not detected
2018.05.29 21:15:27 LOG5[ui]: FIPS mode disabled
2018.05.29 21:15:27 LOG6[ui]: Initializing service [test]
2018.05.29 21:15:27 LOG4[ui]: Service [test] needs authentication to prevent MITM attacks
2018.05.29 21:15:27 LOG5[ui]: Configuration successful
2018.05.29 21:15:27 LOG6[ui]: Service [test] (FD=6) bound to ::1:12345
2018.05.29 21:15:27 LOG6[ui]: Service [test] (FD=7) bound to 127.0.0.1:12345

$ netstat -an | grep 12345
tcp        0      0 127.0.0.1:12345         0.0.0.0:*               LISTEN     
tcp6       0      0 ::1:12345               :::*                    LISTEN     



Specifying numeric IPv4 or IPv6 addresses in the configuration file works too and stunnel will then only listen on the configured address, as configured.

So, I think your release is good to go :-) Thanks for checking!