Upgrade OpenSSL

[SebTM]

Description of the bug

NixOS/nixpkgs#210452

OpenSSL 1.1 is flagged as insecure and will be removed for the next stable NixOS release as it's EOL 09/2023. I'm using sublime-text4 as primary editor (on a daily basis) and wanted to ensure that its on the radar to avoid issues ✌️

Steps to reproduce

Try to install sublime-text* on NixOS unstable or later on 23.05

Expected behavior

OpenSSL 3 or alternative used

Actual behavior

Sublime Text build number

4150

Operating system & version

NixOS unstable

(Linux) Desktop environment and/or window manager

Sway/Wayland

Additional information

No response

OpenGL context information

No response

[BenjaminSchaaf]

The issue with OpenSSL 3 is that ST relies on python 3.3, which only supports OpenSSL 1.0. To avoid packaging issues we ship OpenSSL libraries on all platforms.

[RaitoBezarius]

Is there any plan to upgrade Python also to a non-EOL version of 10 years?
Also, so, your plan is to ship vulnerable OpenSSL 1.0 versions or how do you plan to deal with new vulnerabilities that won't be fixed as OpenSSL 1.1 is EOLed soon?

[BenjaminSchaaf]

We also ship Python 3.8. Python 3.3 is for backwards compatibility with plugins and thus can't be upgraded without breaking functionality.

Up until very recently we shipped both OpenSSL 1.0 and 1.1 but with a lot of effort we backported 1.1 to python 3.3 in build 4145. It's unlikely OpenSSL 3 will be backported to Python 3.3 any time soon, especially when there's little security to be gained from doing so.

For reference package control uses the oscrypto library instead of the packaged OpenSSL to avoid security issues. Similarly updates are not done using OpenSSL.

[SebTM]

Isn't there a point where this strategy does not work out and you will have to abandon the old python and is there a roadmap? I would rather refrain from some plugins than keeping a maybe some-when security hazard?

Also is there a possibility on package-control or somewhere to see if / what python-version it's using to at least avoid using plugins that use these old python-version? Is the plugin-host itself python 3.8+ compatible so I could use a newer version if I don't use plugins require the old version?

[deathaxe]

All packages compatible with python 3.8 contain a .python-version in root directory with 3.8 as contetnt.

Dropping python 3.3 will however render 99.8% of all packages/plugins useless. Nearly none has been migrated to python 3.8 and it is very unlikely to happen any time soon (at all).

With some luck most open-source packages run without any code changes, but ST requires them to contain the said .python-version file to opt-in to py3.8

With most packages being no longer maintained there's little chance to get that file into existing repos. There's the idea of providing required "flag" via Package Control's channel.json upstream, but this requires PC4.0 to be released. While client is (IMHO) ready to go, we need to wait for required packagecontrol.io changes to be made upstream to get started. After that some volunteers need to visit each of the 5k packages, check whether they run on py38 and flag them in PC's channel.

Will there be enough to get that job done?

Beyound that some famous packages ship compiled py33 plugins only. Those can't be migrated by someone else, than original author.

So either go the hard (Kodi) way and just drop 99.8% of packages or keep python 3.3 alive.

Concerns are paranoid with an objective look at OpenSSL's usage in ST plugins. Nearly none makes use of network functionality at all.

Package Control uses wininet.dll on Windows by default and urllib on Linux/Mac. The latter indeed relies on ST's OpenSSL. But even PC3.4's oscrypto library only supports OpenSSL 1.1, which has been the cause of trouble for Mac users recently. PC4.0 shipps latest available oscrypto which uses OpenSSL3 if available - but that's not the standard driver.

EDIT: oscrypto downloader uses ST's OpenSSL library on Linux as it would cause issues otherwise as it seems.

see: https://github.com/wbond/package_control/blob/62730ae34f30a9f3c5ba4849f2d5cfaac24304ff/package_control/downloaders/oscrypto_downloader.py#L29-L42

[deathaxe]

Is the plugin-host itself python 3.8+ compatible so I could use a newer version if I don't use plugins require the old version?

ST starts two separate processes, a plugin_host-3.3 and a plugin_host-3.8 without regards to whether plugins are present or not.

[eproxus]

With some luck most open-source packages run without any code changes

That sounds like a case for assuming Python 3.8 by default at some point, perhaps?

Is it fair to say the current strategy is not scaling? What will happen when 3.8 is “too old”?

[deathaxe]

With most packages/plugins just being dropped but never seriously maintained, the answer with regards to scaling is probably "yes".

Assuming backward compatibility would at least not work well for compiled modules or those relying on (compiled) libraries/dependencies. It would currently also break all plugins, which rely on libraries/dependencies, as Package Control 3.x can't deal with both plugin_hosts at the same time.

Not an issue so far, but maybe a new plugin_host may introduce breaking API changes, which need little adjustments to some plugins. So at least a review might be needed to ensure everything keeps working.

The one way or the other. Changing plugin hosts needs adjustments here and there and can't be handled automatically.

[neilmayhew]

Would it work to provide a dummy version of libssl.so.1.1 that just returns an error for all the APIs? That way the huge majority of plugins that don't do any network i/o would continue to work, but there would be no security risk.

[AngryAnt]

@deathaxe Why the downvote on that suggestion? As you point out:

Concerns are paranoid with an objective look at OpenSSL's usage in ST plugins. Nearly none makes use of network functionality at all.

So objectively there is no issue simply removing OpenSSL 1.1.

While the prospect of "all plugins must be updated or abandoned" is quite hairy, one of "the few plugins making use of network functionality must be updated or abandoned" seems a lot less so and an actually sustainable way forward?

[AngryAnt]

Update on the scenario on NixOS: 23.05 has shipped and Sublime Text is now indirectly marked as an insecure package.

To be clear: Sublime Text no longer has an installable version in a default nixpkgs configuration.

[deathaxe]

OpenSSL is shipped for a reason. Some plugins use it (via urllib) to establish encrypted connnections. E.g. Package Control wouldn't work without it on unix/macos as it uses urllib as default downloader. Hence replacing opennssl with dummy functions is just a dump idea.

Using latest OpenSSL is nothing python based plugins can (easily) fix on their end. Loading a 2nd openssl lib into python environement may even cause conflicts.

On the other hand no risk is to be concerned by plugins not making use of it.

But finally it's up to sublimehq to decide how to cope with this request. I am just a user.

[neilmayhew]

Thanks. That's helpful information.

The OpenSSL migration guide says,

… any application that currently uses an older version of OpenSSL will at the very least need to be recompiled in order to work with the new version. It is the intention that the large majority of applications will work unchanged with OpenSSL 3.0 if those applications previously worked with OpenSSL 1.1.1.

I wonder if it would be possible to modify the 3.3 plugin host to use OpenSSL 3.0. As far as I can tell, the hosts don't use the system-installed Python at all, and instead use a statically linked copy of libpython and ship their own copy of the standard library as .pyo or .pyc files. urllib imports ssl which imports the native-code _ssl module which is bundled inside the plugin host. So the entire chain down to importing libssl is bundled within ST and is under the complete control of ST. Due to the source-level compatibility between OpenSSL 1.1.1 and 3.0, it probably wouldn't be hard to compile _ssl.c against 3.0 instead of 1.1.1, and ST plugins wouldn't know the difference.

[neilmayhew]

I've just noticed that plugin_host-3.3 doesn't link against libssl at all, so it probably has a statically linked copy.

$ readelf -d plugin_host-3.3 | grep Shared
 0x0000000000000001 (NEEDED)             Shared library: [librt.so.1]
 0x0000000000000001 (NEEDED)             Shared library: [libdl.so.2]
 0x0000000000000001 (NEEDED)             Shared library: [libutil.so.1]
 0x0000000000000001 (NEEDED)             Shared library: [libm.so.6]
 0x0000000000000001 (NEEDED)             Shared library: [libpthread.so.0]
 0x0000000000000001 (NEEDED)             Shared library: [libc.so.6]
 0x0000000000000001 (NEEDED)             Shared library: [ld-linux-x86-64.so.2]

plugin_host-3.8 however does:

$ readelf -d plugin_host-3.8 | grep Shared
 0x0000000000000001 (NEEDED)             Shared library: [librt.so.1]
 0x0000000000000001 (NEEDED)             Shared library: [libdl.so.2]
 0x0000000000000001 (NEEDED)             Shared library: [libcrypto.so.1.1]
 0x0000000000000001 (NEEDED)             Shared library: [libssl.so.1.1]
 0x0000000000000001 (NEEDED)             Shared library: [libutil.so.1]
 0x0000000000000001 (NEEDED)             Shared library: [libm.so.6]
 0x0000000000000001 (NEEDED)             Shared library: [libpthread.so.0]
 0x0000000000000001 (NEEDED)             Shared library: [libc.so.6]
 0x0000000000000001 (NEEDED)             Shared library: [ld-linux-x86-64.so.2]