Usage of 'ssl' setting is deprecated and will be removed in v1.21. Please use 'tls' instead
stokito opened this issue · comments
I installed the sslh on Ubuntu 23.10 and got this message in logs after start.
The version installed is 1.20-1.1
The warning (and later an error) is caused by the line the following line in /etc/default/sslh:
DAEMON_OPTS="--user sslh --listen <change-me>:443 --ssh 127.0.0.1:22 --ssl 127.0.0.1:443"
The file is part of a deb package in /debian/default
I reported a bug to Ubuntu but probably I have to report it to a Debian.
https://bugs.launchpad.net/ubuntu/+source/sslh/+bug/2045970
Anyway, it looks like during a next upgrade to v1.21 many users who have the --ssl will get a broken config because the option was removed.
Could you please undeprecate the --ssl and release a version v1.22 that will still support the old version?
You can still keep it removed in a next major release v2.0. So users should know that they have to re-check their configs and read release notes.
I am confused as to what the issue is: v1.20 announced the removal in v1.21, then v1.21 removed it so the problem is... what?
Also, all these versions are 2 years old and I'd encourage anyone to upgrade to 2.0.x.
I also don't understand why you'd want a new v1.22 (which already exists -- if any new version were created, it'd be... v1.20b? I don't know, it doesn't fit in the previous versioning scheme) branch, who would use this?
The current version installed from Ubuntu repository is v1.20.
Usually maintainers trying to upgrade to last version in the 1.x series before switching to the 2.x. This is usually needed because the each version may have own migrations. The mayor version upgrades are usually happen with a next version of a distro e.g. Ubuntu 24.04.
So what is going to happen is that at any point of time distro will upgrade to the v1.21 then many users will upgrade their systems and found them broken.
Maybe that's one of the reason why they still didn't upgraded version and still using a 2 years old that "definitely work".
Understood. I guess that would be a 1.23, that adds --ssl to 1.22c.
I am not totally sure that's doable, if I remember correctly there was a major refactor of the configuration system between the two versions, which may cause problems... and there might be other major changes (I wasn't using semantic versioning back then, so there is probably more difference between 1.21 and 1.22 than there is between 1.22 and 2.0.0). I'll look into it.
I checked and for the next release the version would be indeed the 1.22c.
It turned out that the Ubuntu just republish the package from Debian.
It contains some patches that maybe you can grab to here https://salsa.debian.org/debian/sslh/-/tree/master/debian/patches?ref_type=heads
I created a PR to the debian/default file to replace the --ssl
https://salsa.debian.org/debian/sslh/-/merge_requests/2
The Debian package is maintained by @dondelelcaro (don@debian.org Debian IRC: dondelelcaro)
Maybe you guys can collaborate closer? Maybe you @yrutschle can also become a maintainer of own package. And grab the debian folder into the repo and then @dondelelcaro can make direct commits into the folder. With .github/CODEOWNERS you can grant a commit access to a specific folder.
As you see, for me this was tricky to understand to whom and where to report and fix the problem.
The idea that configuration file /etc/default/sslh is not here but in Debian salsa Gitlab repo makes me sad.
First of all you as an author didn't know that that config use the deprecated -ssl. If the file will be here then you will easily found this yourself.
Also I believe that other distros (e.g. Arch, AlmaLinux) may have exactly same config file but with different content that may add a confusion for users who need to use different instructions. That also means that those distros may have a similar bug and use the --ssl.
I just checked my OpenWrt router and it uses the --tls everywhere, 👍
Generally speaking, I would ask you to un-deprecate the option in v2 ether.
For me it looks like not a big deal but many howtos and vidoe tutorials may use the -ssl. This product is used in sensitive situations when users trying to unlock restrictions and they may not have a good instruction. Many of them are non English speakers.
You won't rename the sslh to tlsh, right? 😉
P.S. some bugs are reported in Ubuntu bug tracker that may be interesting for you (one was mine):
https://bugs.launchpad.net/ubuntu/+source/sslh
I was just looking through the code, and I can't remember what the reason for deprecating --ssl was: I agree it should be trivial to re-enable it on 2.0.
I have mixed feelings about integrating distro-specific things in the main repository: that means it would be expected for all distros to work "out of the repo", and I certainly wouldn have time to maintain that.
I'll check out the Debian patches, thanks.
Funny you asked about renaming to tlsh (or tlssh?), I was wondering about that too :-) (but I guess the name sslh it too well established now)
I have mixed feelings about integrating distro-specific things in the main repository
Debian (so and Ubuntu, Raspbian) for sure is used by most of users of the sslh. The maintainer still have an ability to apply own patches but it would be much easier to keep an eye on the changes and don't miss something important. Anyway users will report a bug to you even if it's related to a distro specific file.
Here we go:
- There is now a 'v1.23' branch, to push fixes to pre-v1.22c fixes.
- v1.23.0 reintroduces
--ssl - it's been tagged and pushed to the web site
I guess it'd be worth coming through all the commits after v1.22c to backport feature fixes on v1.23, but I'm not sure I'll get the motivation to do so. Maybe if I see people re-opening issues on v1.23 :)
I've moved your comments about Debian to another issue to not lose track of them.
I'm closing this now, but do re-open if I missed something (I'm more of a developer than a long-term maintainer, but still I feel the pain of maintenance and am happy to help them as long as it remains a reasonable effort on my part :-) ).
thank you!