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]

[neilmayhew]

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.

OK, so maybe backporting OpenSSL 3.0 to the 3.3 host isn't easy, then. However, I'm not sure why 3.8 is still using 1.1. If the 3.3 host uses a statically linked 1.1 and the 3.8 hosts used a dynamic 3.0, things would look OK from the outside. No deprecated dynamic library package would be needed from the OS. Or the 3.8 host could use a static copy of the library too.

[BenjaminSchaaf]

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

This changed in build 4145. Previously we statically linked openssl 1.0.

[AngryAnt]

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.

Ah! I believe you simply misunderstood the suggestion then. The outline given the data you provided is this:

• Python 3.3, where most plugins (but very few making use of SSL) sit requires OpenSSL 1.1.
• Python 3.8 uses latest OpenSSL.
• Replacing OpenSSL 1.1 with a dummy would result in:
  • The small intersection of "Python 3.3" and "making use of SSL" breaks.
  • These affected plugins need to either be upgraded to Python 3.8 where latest OpenSSL is available. Or they get abandoned.
  • All other plugins are unaffected.

I don't see how that is not a very sustainable path forward, completely bypassing the SSL porting race?

[rchl]

• The small intersection of "Python 3.3" and "making use of SSL" breaks.

How small is the intersection according to you?
Didn't @deathaxe say that Package Control itself need it? If so then it pretty much affects 100% of users and packages.
Also many packages make requests to HTTPS endpoints which I'm assuming also needs OpenSSL.

[AngryAnt]

• The small intersection of "Python 3.3" and "making use of SSL" breaks.

How small is the intersection according to you? Didn't @deathaxe say that Package Control itself need it? If so then it pretty much affects 100% of users and packages. Also many packages make requests to HTTPS endpoints which I'm assuming also needs OpenSSL.

I do not presume to make such a determination. As I explicited in the very comment you are replying to, all I have to go by is the conversation we are currently having. In that conversation, those datapoints were provided and then the opposite conclusion was drawn - which led to my puzzlement.

Specifically for "how small", I am going off what you can see a stated and then quoted a bit further up:

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

I am taking the creative liberty of translating "nearly none" to "a small intersection". I can make the edit if you prefer I use the original language.

[AngryAnt]

Didn't @deathaxe say that Package Control itself need it?

They did indeed. Would you assume that the decision on that specific package is to abandon it rather than upgrade?

[simonspa]

They did indeed. Would you assume that the decision on that specific package is to abandon it rather than upgrade?

I would say the opposite :) If you check the repository (https://github.com/wbond/package_control/tree/four-point-oh) there is tons of work already in the four-point-oh branch, and since last week even a 4.0-beta1 tag available.

[rchl]

Package Control is THE package manager of Sublime Text. No normal user would realistically use ST without it since it would be a pain to manage packages otherwise. Abandoning it is clearly not an option.

I believe that there is a new version of it in the works that might be using the 3.8 host but it has been in the works for many years now so not holding breath on this one.

[AngryAnt]

They did indeed. Would you assume that the decision on that specific package is to abandon it rather than upgrade?

I would say the opposite :) If you check the repository (https://github.com/wbond/package_control/tree/four-point-oh) there is tons of work already in the four-point-oh branch, and since last week even a 4.0-beta1 tag available.

Nice :) Sensible foresight and rapidly approaching this aspect of OpenSSL upgrading being a non-issue :)

[rchl]

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

I am taking the creative liberty of translating "nearly none" to "a small intersection". I can make the edit if you prefer I use the original language.

Not sure about that. Many "AI coding" packages that are popular these days have to make requests to an API.
Also many LSP-* packages manage language servers themselves by downloading those from github etc.

[Nairou]

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

This changed in build 4145. Previously we statically linked openssl 1.0.

Will this fix the issue of the Preferences menu options being greyed out (can't edit settings) if plugin_host fails to load?

I continue to use ST under NixOS by overriding the openssl 1.1.1 dependency, but that apparently removes more than just plugin support.

[nh2]

Could there be a setting that, if enabled, tells users (thus also plugin developers) when they use a package that's not compatible with Sublime's preferred more current Python version, and what those plugins are?

Without a way to notice that this issue even exists, people will not fix it in their plugins.

(I also wrote a plugin in Sublime Text 2 times and only learned of the concept of .python-version now because NixOS alerted me of the insecure OpenSSL.)

[jtojnar]

I continue to use ST under NixOS by overriding the openssl 1.1.1 dependency, but that apparently removes more than just plugin support.

Do not do that. Despite the confusing error message, OpenSSL 1.1 is still supported and updated in NixOS for now. So the only thing you will achieve is breaking your installation – many of the Sublime Text features are implemented inside Default.sublime-package.

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

This changed in build 4145. Previously we statically linked openssl 1.0.

Will this fix the issue of the Preferences menu options being greyed out (can't edit settings) if plugin_host fails to load?

No. The Default package, which contains the edit_settings command uses plugin_host-3.8, which we have already been patching to use OpenSSL from NixOS for a while now. So if you are removing openssl_1_1 dependency, you will just get even more breakage after 4045.

[phredistaken]

Tenable is flagging openssl in sublime: https://www.tenable.com/plugins/nessus/171079

Path : /opt/sublime_text/libssl.so.1.1
Reported version : 1.1.1s
Fixed version : 1.1.1t

Path : /opt/sublime_text/libcrypto.so.1.1
Reported version : 1.1.1s
Fixed version : 1.1.1t

[stfnx]

OpenSSL 1.1.1 was released on 11th September 2018, and so it will be considered EOL on 11th September 2023!!! It will no longer be receiving publicly available security fixes after that date.

Sadly Sublime Merge does have the same issue. I will switch to VSCode until this is (hopefully) resolved...

[BenjaminSchaaf]

Sadly Sublime Merge does have the same issue.

No it doesn't. We don't ship openssl with Sublime Merge, since there aren't any plugins.

[deathaxe]

Well, to be fair, Sublime Merge 2090 ships with Git for Windows 2.39.1, which still uses openssl 1.1.

Git for Windows 2.42.0 uses openssl3.

[BenjaminSchaaf]

Right, I was thinking of Linux where we don't ship git.

[appsforartists]

Nobody wants to be using insecure software, but it sounds like the risk profile here is "if you use a plugin that depends on OpenSSL and a new vulnerability is discovered that won't be patched, that vulnerability could be exploited in that plugin." I'm not a security engineer, but that sounds like a relatively small exposure.

It also sounds like you can patch the vulnerability down to 0 if you test the packages you use with .python-version = 3.8 and upstream that fix.

One nice aspect of NixOS is that Sublime's dependency on an old OpenSSL doesn't leak into other applications.

[RaitoBezarius]

Nobody wants to be using insecure software, but it sounds like the risk profile here is "if you use a plugin that depends on OpenSSL and a new vulnerability is discovered that won't be patched, that vulnerability could be exploited in that plugin." I'm not a security engineer, but that sounds like a relatively small exposure.

Unfortunately, we don't have the people to perform such in-depth analysis, and I think the past proved that this is hard to predict properly. Thus, we apply the principle of precaution first and foremost.

It also sounds like you can patch the vulnerability down to 0 if you test the packages you use with .python-version = 3.8 and upstream that fix.

I am not sure how we can patch the vulnerability given that OpenSSL will not receive eyes anymore, so at some point, there will just be no report any more except for users with a subscription.

One nice aspect of NixOS is that Sublime's dependency on an old OpenSSL doesn't leak into other applications.

Certainly, but, OpenSSL 1.1.x is slated for removal for NixOS 24.05.