Hi, thanks for reporting this bug.
As there is no maintainer for this package I added the committers in CC.

(Please set the status to 'assigned' if you are working on it)

CC: (none) => mageia

3 monthly ping. still no maintainer (and same version in cauldron as in Mga 1)

CC: (none) => marja11

This package could obviously use some love. It turns out that the lib packages arn't even necessary. The library is a run-time dynamic linkable library that is useless to other programs, so it should be packaged with stunnel itself. The .a library is similarly useless and should be removed.

The attached patch fixes these issues. It also fixes two others that I discovered. The first is that the build halts when run locally due to interactive certificate generation. The second is the invalid default paths in the stunnel.conf file and redundant stunnel.conf-sample file.

I'm also suspicious about /etc/stunnel/ as the location for the PEM files and why a pre-built file stunnel.pem is being included, but this patch is already an improvement.

Created attachment 2628 [details]
Fixes many stunnel packaging issues

and the stunnel-4.34-conf.patch patch ? :)

Version: 1 => Cauldron
Whiteboard: (none) => MGA1TOO

That implements the "invalid default paths in the stunnel.conf" problem I mentioned above. The installed paths end up being /usr/etc/stunnel/ and /usr/var/lib/stunnel, which are weird and point to directories that doesn't exist. The first one should perhaps actually be changed to /etc/ssl/stunnel/ instead.

well feel free to provide real file like for the spec ;)

(anyway this package is not really maintained)

Keywords: (none) => Junior_job, PATCH

patch will create that file from the attachment, but I can upload it separately if that's easier, but it might be a bit of time before I can get back to this.

(In reply to comment #7)
> well feel free to provide real file like for the spec ;)
> 
> (anyway this package is not really maintained)

(In reply to comment #8)
> patch will create that file from the attachment, but I can upload it separately
> if that's easier, but it might be a bit of time before I can get back to this.

cc'ing one more committer of stunnel

CC: (none) => guillomovitch

I just fixed the library issue in cauldron. The certificate issue has been already handled by previous release.

Status: NEW => RESOLVED
Resolution: (none) => FIXED

We can issue the fix to Mageia 1 and Mageia 2 as well.

Could one of you (Dan or Guillaume) write an advisory describing the changes that were made, so we can have an advisory for the update?

Status: RESOLVED => REOPENED
CC: (none) => luigiwalser
Version: Cauldron => 2
Resolution: FIXED => (none)

We now have:
stunnel-4.53-1.mga1
stunnel-4.53-3.1.mga2

Which include the following changes:
- upgrade to 4.53 (several bugs fixed upstream)
- move library subpackages back into main stunnel package
- add a systemd unit file (Mageia 2 only, partially fixing Bug 3951)
- fix issues with stunnel.conf and stunnel.pem (hopefully can get a better description for this one from Dan or Guillaume)

Assignee: bugsquad => qa-bugs

The change in configuration was just to use rpm-helper to generate the certificat file in the standard /etc/pki/tls/certs directory.

Thanks Guillaume.

We now have:
stunnel-4.53-1.mga1
stunnel-4.53-3.1.mga2

Which include the following changes:
- upgrade to 4.53 (several bugs fixed upstream)
- move library subpackages back into main stunnel package
- add a systemd unit file (Mageia 2 only, partially fixing Bug 3951)
- fix generation of certificate file in /etc/pki/tls/certs and associated configuration in stunnel.conf

You can use that as a basis for the advisory.

Installation failed:    file /usr/lib64/libstunnel.so from install of stunnel-4.53-3.1.mga2.x86_64 conflicts with file from package lib64stunnel0-4.34-3.mga1.x86_64

It still needs an obsoletes on the old library.

CC: (none) => davidwhodgins

It does:

Obsoletes:      %mklibname %{name} 0 < 4.53-4

OK, that syntax doesn't quite work.  I'll fix it.

Fixed.  Submitted to the build system.  Once it's built, we'll have:

We now have:
stunnel-4.53-1.1.mga1
stunnel-4.53-3.2.mga2

Fixed stunnel packages are uploaded.  Thanks for the report.

It's working on my Mageia 2 x86-64 system, but on my Mageia 1 i586,
I'm getting ...
# /usr/bin/stunnel /etc/ssl/stunnel/stunnel.conf
stunnel 4.53 on i586-mageia-linux-gnu platform
Compiled/running with OpenSSL 1.0.0d 8 Feb 2011
Threading:FORK SSL:+ENGINE+OCSP Auth:LIBWRAP Sockets:POLL+IPv6
Reading configuration from file /etc/ssl/stunnel/stunnel.conf
Failed to initialize compression method
str_stats: 3 block(s), 43 data byte(s), 126 control byte(s)

This is an update to an existing stunnel that was working before
the update, so this is a regression.  I use stunnel for encrypted
connections with leafnode.

# grep -i compres /etc/ssl/stunnel/stunnel.conf
compression=rle

Whiteboard: MGA1TOO => MGA1TOO MGA2-64-OK feedback

Ping!  As per comment 20, stunnel is not working on Mageia 1 i586.

This is using an identical config file to what is working on Mageia 2
x86-64, and that works with the prior version of stunnel.

Were different options selected?  Both of my systems are using rle
compression with stunnel.

Checking under strace, on Mageia 1 i586 it's generating the error
message immediately after reading the stunnel.conf file, without
trying to open any other files, so it looks like rle compression
has been disabled in the Mageia 1 build.

It's the same spec with the only difference being the mga2/cauldron one provides the systemd unit file, so it shouldn't be different.

Guillaume, do you have any idea?

No idea, I never used stunnel myself.

I'll test this one later and see if I get the same.

Whiteboard: MGA1TOO MGA2-64-OK feedback => MGA1TOO MGA2-64-OK

Casting about the net Dave I see stunnel man pages saying:

 "rle compression is currently not implemented by the OpenSSL library."

I wonder if support has been added since then and is present in mga2 but not mga1

Testing mga2 64

Before
------

stunnel gives the command to use to create the pem certificate in the README.urpmi as /etc/ssl/stunnel/stunnel.pem

Other certificates on the system (ldap.pem, cyrus-imap.pem, postfix.pem) are created in /etc/ssl/certs which is a symbolic link to /etc/pki/tls/certs

The cert path in the /etc/stunnel/stunnel.conf is:

; certificate/key is needed in server mode and optional in client mode
cert = /usr/etc/stunnel/mail.pem
;key = /usr/etc/stunnel/mail.pem

Also noticed stunnel installs a 'default' certificate at 
/etc/stunnel/stunnel.pem

Testing with telnet, installed netkit-telnet-server 
Commented out the default settings for pop3s etc and added:

[telnet]
accept = 4444
connect = 23

Left compression off for now.

When run manually it complains of
"Wrong permissions on /etc/ssl/stunnel/stunnel.pem"

# ll /etc/ssl/stunnel/stunnel.pem
-rw-r--r-- 1 root root 1828 Sep 17 14:22 /etc/ssl/stunnel/stunnel.pem

Should be 600 according to http://www.stunnel.org/faq.html

It seems to try to open a tunnel and fail with
"chroot: No such file or directory (2)"

In the conf again, commented out:

chroot = /usr/var/lib/stunnel/

No such file or directory with systemctl start stunnel.service
Started as root..

Cannot create pid file /stunnel.pid
create: Permission denied (13)

It's trying to create a pid file in /
In the conf again, altered the pid path

pid = /var/run/stunnel/stunnel.pid

Then had to chown nobody:nogroup /var/run/stunnel

When started it reports it is running on mandriva..

stunnel 4.34 on x86_64-mandriva-linux-gnu with OpenSSL 1.0.0j 10 May 2012

Connected with:
telnet <host> 4444

I'll install the update and check for some fixes.

Also before:

$ urpmf lib64stunnel0
lib64stunnel0:/usr/lib64/libstunnel.a
lib64stunnel0:/usr/lib64/libstunnel.la
lib64stunnel0:/usr/lib64/libstunnel.so

$ urpmf lib64stunnel-devel
lib64stunnel-devel:/usr/lib64/libstunnel.la
lib64stunnel-devel:/usr/lib64/libstunnel.so

So file conflicts.

After
-----

Confirmed the lib move back into the main package. lib(64)stunnel0 has no update and installing the updated stunnel removes the existing one. It also automatically creates a certificate in the correct place
# urpmi stunnel


    http://192.168.2.222/mirror/distrib/2/x86_64/media/core/updates_testing/stunnel-4.53-3.2.mga2.x86_64.rpm
installing stunnel-4.53-3.2.mga2.x86_64.rpm from /var/cache/urpmi/rpms
Preparing...                     #########################################################
      1/1: stunnel               warning: /etc/stunnel/stunnel.conf created as /etc/stunnel/stunnel.conf.rpmnew
#########################################################
Generating a 1024 bit RSA private key
.......++++++
...................++++++
writing new private key to '/etc/pki/tls/private/stunnel.pem'
-----
removing package lib64stunnel0-4.34-3.mga1.x86_64


Confirmed the systemd service file has been added

# urpmf --media Testing stunnel | grep service
stunnel:/lib/systemd/system/stunnel.service

Confirmed the lib is now part of stunnel

# urpmf --media Testing stunnel | grep libstunnel
stunnel:/usr/lib64/libstunnel.so

Removed the old conf file and renamed the rpmnew.


The certificate path is now correct but the default configuration cannot start without further configuration. 

The systemd service file looks for the pid file in /var/run/stunnel/ but the conf is configured to place the pid file in / so it never finds it and eventually times out.

Once the conf has been changed to pid = /var/run/stunnel/stunnel.pid, commenting the chroot setuid & setgid allows it to be started as a systemd service which seems to be the aim of including it.

Removing mga2 64 OK from whiteboard for now as it cannot start with the systemd service file which has been added in this update without the configuration changes above. Other than that it is Ok with either rle or zlib compression options set.

Requesting packager feedback here please.

Hardware: i586 => All
Whiteboard: MGA1TOO MGA2-64-OK => MGA1TOO feedback

The PID file path is OK, as the process runs in a chroot. That's the last one which was badly configured, I just fixed it to use /run/stunnel in cauldron.

A similar fix has to be propagated also in stable 2 and 1.

The chroot path it uses did not exist, did you correct that part too Guillaume?

I also ensured the chroot path existed.

Additional updated packages uploaded in update_testing:
- stunnel-4.53-1.2.mga1 for mga1
- stunnel-4.53-3.3.mga2 for mga2

Testing complete on Mageia 2 x86-64.

Mageia 1 i586 still fails with
Failed to initialize compression method.

Once Mageia 2 i586 has been tested, I think this update should be validated
for Mageia 2 only, and the Mageia 1 update held until we can figure out why
compression stops working after the update.

The config file I'm using has ...
# cat /etc/ssl/stunnel/stunnel.conf
debug=info
foreground=no
syslog=yes
compression=rle
[nntps]
client=yes
connect=news.eternal-september.org:563
accept=564

Leafnode's config file has
expire = 7
server = localhost
port = 564
username = dwhodgins
password = mungedforbugreport
timeout = 300
timeout_fetchnews = 300
initialfetch = 500
nodesc = 1
maxage = 5
filterfile = /etc/leafnode/filters
debugmode = 0
create_all_links = 0
allow_8bit_headers = 1
article_despite_filter = 1
noxover = 1

Whiteboard: MGA1TOO => MGA1TOO MGA2-64-OK

Note that the stunnel man page says "rle compression is currently not implemented by the OpenSSL library". Actually, all of the compression schemes give an error for me under Mageia 1, but without compression both client and server modes worked fine for me.

(In reply to comment #32)
> Note that the stunnel man page says "rle compression is currently not
> implemented by the OpenSSL library". Actually, all of the compression schemes
> give an error for me under Mageia 1, but without compression both client and
> server modes worked fine for me.

Agreed.  Despite what the man page says, with the Mageia 1 Core Release
version, and prior versions since Mandriva 2009.0, I was never able to get
deflate or zlib working, but rle has been working.  When I was first trying
to get it working, I assumed the problems with deflate and zlib were due
to the software at the other end of the tunnel.

My guess is the difference in the openssl versions, it's compiled with, as I
don't see any difference between the Mageia 1/2 srpms that I would expect to
cause the problem.

I'll test with Mageia 2 i586 shortly.

When this update is validated for Mageia 2, should I open a new bug report
for Mageia 1, or just request that this update be removed from Mageia 1
Core Updates testing, and forget about this update for Mageia 1?

(In reply to comment #33)
> When this update is validated for Mageia 2, should I open a new bug report
> for Mageia 1, or just request that this update be removed from Mageia 1
> Core Updates testing, and forget about this update for Mageia 1?

Since it's not a security update and doesn't fix any critical issues, it's probably OK to drop it for Mageia 1.

Testing complete on Mageia 2 i586.

Could someone from the sysadmin team push the srpm
stunnel-4.53-3.3.mga2.src.rpm
from Mageia 2 Core Updates testing, to Core Updates.

Advisory:  This bugfix upgrade of stunnel to 4.53 fixes ...
- move library subpackages back into main stunnel package
- add a systemd unit file (Mageia 2 only, partially fixing Bug 3951)
- fix issues with stunnel.conf and stunnel.pem, with stunnel
  running in a chroot environment.

https://bugs.mageia.org/show_bug.cgi?id=4223

Also please remove the srpm
stunnel-4.53-1.2.mga1.src.rpm
from Mageia 1 Core Updates testing, and the associated rpm packages.

Keywords: (none) => validated_update
CC: (none) => sysadmin-bugs
Whiteboard: MGA1TOO MGA2-64-OK => MGA2-64-OK MGA2-32-OK

The part for the systemd unit file doesn't need to say Mageia 2 only now if this update is Mageia 2 only :o)  I'm not sure if the chroot issue affected the release version or just the update candidate; if the former, that could be mentioned too.

One concern though, Obsoletes tags should always be versioned, which I had fixed, but Guillaume reverted it.

Update pushed:
https://wiki.mageia.org/en/Support/Advisories/MGAA-2012-0196

Mga1 updates_testing cleaned

Status: REOPENED => RESOLVED
CC: (none) => tmb
Resolution: (none) => FIXED