search

yrutschle / sslh

Applicative Protocol Multiplexer (e.g. share SSH and HTTPS on the same port)
https://www.rutschle.net/tech/sslh/README.html
GNU General Public License v2.0
4.55k stars 368 forks source link

Consider merging Debian package support into sslh repository #419

Open yrutschle opened 9 months ago

yrutschle commented 9 months ago

@stokito makes good points:

          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

Originally posted by @stokito in https://github.com/yrutschle/sslh/issues/416#issuecomment-1861669433

stokito commented 6 months ago

The Debian susyemd service has only a few dirrerences:

It has:

Documentation=man:sslh(8)

It uses EnvironmentFile=/etc/default/sslh instead of /etc/conf.d/sslh. In Debian almost all configs are located in the /etc/default/ but the /etc/conf.d/ folder maybe a default in other distros like in Gentoo https://wiki.gentoo.org/wiki//etc/conf.d On the RedHat is also used the /etc/default. So let's change it too here.

It has an additional CAP_SETGID CAP_SETUID which is not needed anymore we set a user on the SystemD unit file https://salsa.debian.org/debian/sslh/-/merge_requests/2/diffs?commit_id=02703eebaf9c1089447ccaa0828c69ee3a5e773d.

So basically not so many changes needed in the service file.

yrutschle commented 6 months ago

@stokito fee8491 should take in account the environment and capabilities remarks I'll try to contact Don on Salsa to see about merging debian/ here.

stokito commented 6 months ago

Thank you. The Documentation=man:sslh(8) looks like anyway not useful.

ftasnetamot commented 4 months ago

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.

I see it different: Having a longer time, announcing deprecation of some features, gives people the possibility to change things. It creates also awareness, that not all packages in distros are well maintained, and that you have to dig into. So I see there no problem, making this in next or the version after the next deprecated. It can still drop a specific error message, like: "did you mean tls?" Your comparision to ssh is completly wrong, as the ssl-protocol is dead, deprecated since 10 years! The ssh protocol is still alive under this name. When doing due diligence in softwareprojects, the word "ssl" triggers big red warnings, as this can be a strong incidence of the using insecure protocols!