Bug 1112830 - Out of date package: openSUSE:Factory/stunnel
Out of date package: openSUSE:Factory/stunnel
Status: RESOLVED FIXED
Classification: openSUSE
Product: openSUSE Tumbleweed
Classification: openSUSE
Component: Other
Current
Other Other
: P5 - None : Enhancement (vote)
: ---
Assigned To: Daniel Rahn
E-mail List
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2018-10-23 01:49 UTC by Sean Lewis
Modified: 2018-11-24 18:51 UTC (History)
4 users (show)

See Also:
Found By: ---
Services Priority:
Business Priority:
Blocker: ---
Marketing QA Status: ---
IT Deployment: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Sean Lewis 2018-10-23 01:49:48 UTC
https://build.opensuse.org/package/show/security:Stunnel/stunnel is out of date. Current upstream is available at https://www.stunnel.org/downloads/stunnel-5.49.tar.gz.
Comment 1 Andreas Vetter 2018-10-24 08:47:46 UTC
@Sean: 
Does the provided version 5.44 have a problem (I'm not aware of any)? Or do you need new features (something in 5.49 or 5.50beta)?

I see you branched stunnel in OBS. If it is not a bug, you could have also left a comment in OBS, asking for a newer version.

As for all packages: you are invited to help by branching, build a newer version, test and submit. I will happily review and accept or propose a change.
Comment 2 Sean Lewis 2018-10-24 13:54:16 UTC
@Andreas, I went to branch it but am having some issues with my OBS build environment that is preventing it from building properly. Just went to check it out for use and noticed there's a newer version that should be rolling into TW/Factory for testing.
Comment 3 Andreas Vetter 2018-10-24 14:28:39 UTC
Ok, I'll try with 5.49. Will have to rebase the listenqueue patch as always.

@Daniel: 1. Do we still need it? IIUC, it is used to reduce listenqueue below SOMAXCONN. 
2. Is it possible to submit the patch upstream? Who is the author, what's the license?
Comment 4 Daniel Rahn 2018-11-06 06:38:39 UTC
(In reply to Andreas Vetter from comment #3)

> @Daniel: 1. Do we still need it? IIUC, it is used to reduce listenqueue
> below SOMAXCONN. 
> 2. Is it possible to submit the patch upstream? Who is the author, what's
> the license?

The patch was rejected by upstream. It is however an important feature in the SUSE package for performance optimization. Same license as the stunnel package.
Comment 5 Stefan Botter 2018-11-11 09:10:45 UTC
@Andreas: with respect to your comment 1:
 
I did not test with Tumbleweed, but with 15.0 there is a problem with version 5.44:

Nov 11 09:58:24 knecht systemd[1]: Starting SSL tunnel for network daemons...
Nov 11 09:58:24 knecht stunnel[23632]: [ ] Clients allowed=500
Nov 11 09:58:24 knecht stunnel[23632]: [.] stunnel 5.44 on x86_64-suse-linux-gnu platform
Nov 11 09:58:24 knecht stunnel[23632]: [.] Compiled with OpenSSL 1.1.0h-fips  27 Mar 2018
Nov 11 09:58:24 knecht stunnel[23632]: [.] Running  with OpenSSL 1.1.0i-fips  14 Aug 2018
Nov 11 09:58:24 knecht stunnel[23632]: [.] Threading:PTHREAD Sockets:POLL,IPv6 TLS:ENGINE,FIPS,OCSP,PSK,SNI Auth:LIBWRAP
Nov 11 09:58:24 knecht stunnel[23632]: [ ] errno: (*__errno_location ())
Nov 11 09:58:24 knecht stunnel[23632]: [.] Reading configuration from file /etc/stunnel/stunnel.conf
Nov 11 09:58:24 knecht stunnel[23632]: [.] UTF-8 byte order mark not detected
Nov 11 09:58:24 knecht stunnel[23632]: [.] FIPS mode disabled
Nov 11 09:58:24 knecht stunnel[23632]: [ ] Compression disabled
Nov 11 09:58:24 knecht stunnel[23632]: [ ] Snagged 64 random bytes from /dev/urandom
Nov 11 09:58:24 knecht stunnel[23632]: [ ] PRNG seeded successfully
Nov 11 09:58:24 knecht stunnel[23632]: [ ] Initializing service [nntp]
Nov 11 09:58:24 knecht stunnel[23632]: [ ] Ciphers: HIGH:!DH:!aNULL:!SSLv2
Nov 11 09:58:24 knecht stunnel[23632]: [ ] TLS options: 0x02020004 (+0x02000000, -0x00000000)
Nov 11 09:58:24 knecht stunnel[23632]: [ ] No certificate or private key specified
Nov 11 09:58:24 knecht stunnel[23632]: [:] Service [nntp] needs authentication to prevent MITM attacks
Nov 11 09:58:24 knecht stunnel[23632]: [.] Configuration successful
Nov 11 09:58:24 knecht stunnel[23632]: [ ] Binding service [nntp]
Nov 11 09:58:24 knecht stunnel[23632]: [ ] Listening file descriptor created (FD=7)
Nov 11 09:58:24 knecht stunnel[23632]: [ ] Option SO_REUSEADDR set on accept socket
Nov 11 09:58:24 knecht stunnel[23632]: [ ] Service [nntp] (FD=7) bound to 127.0.0.1:119
Nov 11 09:58:24 knecht stunnel[23632]: [ ] Listening file descriptor created (FD=8)
Nov 11 09:58:24 knecht stunnel[23632]: [ ] Option SO_REUSEADDR set on accept socket
Nov 11 09:58:24 knecht stunnel[23632]: [!] bind: Address already in use (98)
Nov 11 09:58:24 knecht stunnel[23632]: [!] Error binding service [nntp] to 127.0.0.1:119
Nov 11 09:58:24 knecht stunnel[23632]: [ ] Unbinding service [nntp]
Nov 11 09:58:24 knecht stunnel[23632]: [ ] Service [nntp] closed (FD=7)
Nov 11 09:58:24 knecht stunnel[23632]: [ ] Service [nntp] closed
Nov 11 09:58:24 knecht systemd[1]: stunnel.service: Control process exited, code=exited status=1
Nov 11 09:58:24 knecht systemd[1]: Failed to start SSL tunnel for network daemons.

The relevant config lines leading up to this are
======
client = yes
chroot = /var/lib/stunnel/
setuid = stunnel
setgid = nogroup
pid = /var/run/stunnel.pid
socket = l:TCP_NODELAY=1
socket = r:TCP_NODELAY=1
[nntp]
accept = localhost:119
connect = server.example.com:443
======

The error "[!] bind: Address already in use (98)" is documented in upstream mailing list here:
https://www.stunnel.org/pipermail/stunnel-users/2018-February/005935.html
and in the following posts in that thread.
The fix for this was introduced in 5.45b2 and is remaining fixed in newer versions.

As stunnel is refusing to work with correct config files (correct for older and newer versions), the severity should be increased to "major".
Comment 6 Stefan Botter 2018-11-11 11:15:47 UTC
submitted rq 648213 to security:Stunnel for update to 5.49.
I had to disable %checks in spec file, as checks depend on ncat and network resources.
Comment 7 Andreas Vetter 2018-11-11 16:58:32 UTC
Request Accepted.
Thank you
Comment 8 Andreas Vetter 2018-11-24 18:51:14 UTC
new version provided