salt-ssh: ssl.SSLError: unknown error (_ssl.c:2788)

Bug #1809452 reported by Iain Buclaw
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
salt (Debian)
Fix Released
Unknown
salt (Ubuntu)
Incomplete
Undecided
Unassigned

Bug Description

See also https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=910236

As per Debian bug, importing the module directly / running the problematic code in python interpreter works fine.

On debugging, I found another error reproducible with the following:

---
>>> import ssl
>>> if ssl is not None:
... # Note that the naming of ssl.Purpose is confusing; the purpose
... # of a context is to authentiate the opposite side of the connection.
... _client_ssl_defaults = ssl.create_default_context(
... ssl.Purpose.SERVER_AUTH)
... _server_ssl_defaults = ssl.create_default_context(
... ssl.Purpose.CLIENT_AUTH)
... if hasattr(ssl, 'OP_NO_COMPRESSION'):
... # See netutil.ssl_options_to_context
... _client_ssl_defaults.options |= ssl.OP_NO_COMPRESSION
... _server_ssl_defaults.options |= ssl.OP_NO_COMPRESSION
...
>>> import salt.utils.rsax931
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib/python3/dist-packages/salt/utils/rsax931.py", line 85, in <module>
    libcrypto = _init_libcrypto()
  File "/usr/lib/python3/dist-packages/salt/utils/rsax931.py", line 76, in _init_libcrypto
    raise OSError("Failed to initialize OpenSSL library (OPENSSL_init_crypto failed)")
OSError: Failed to initialize OpenSSL library (OPENSSL_init_crypto failed)
---

I found an upstream bug (https://github.com/saltstack/salt/issues/46884) which has already been fixed with following patch.

https://patch-diff.githubusercontent.com/raw/saltstack/salt/pull/48580.patch

Back to the original error, this is a minimal test for it.

---
>>> from ctypes import cdll
>>> libcrypto = cdll.LoadLibrary('libcrypto.so.1.1')
>>> libcrypto.OPENSSL_init_crypto(140, None)
1
>>> import ssl
>>> ssl.create_default_context(ssl.Purpose.SERVER_AUTH)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib/python3.6/ssl.py", line 502, in create_default_context
    context = SSLContext(PROTOCOL_TLS)
  File "/usr/lib/python3.6/ssl.py", line 391, in __new__
    self = _SSLContext.__new__(cls, protocol)
ssl.SSLError: unknown error (_ssl.c:2788)
---

If you reverse the ssl and libcrypto parts, OPENSSL_init_crypto instead returns zero. So the underlying problem is the order of which imports are done. Tornado (ergo ssl) _must_ be imported first before the libcrypto library loading in salt are ran, otherwise the program dies.

I couldn't see any specific fix in salt relating to this error, however the package version (2017.7.4+dfsg1-1) is sorely out of date with the current release (2018.3.x), maybe this new version fixes this indirectly with some import refactorings.

ProblemType: Bug
DistroRelease: Ubuntu 18.10
Package: salt-ssh 2017.7.4+dfsg1-1
ProcVersionSignature: Ubuntu 4.18.0-12.13-generic 4.18.17
Uname: Linux 4.18.0-12-generic x86_64
ApportVersion: 2.20.10-0ubuntu13.1
Architecture: amd64
CurrentDesktop: pop:GNOME
Date: Fri Dec 21 12:17:09 2018
PackageArchitecture: all
SourcePackage: salt
UpgradeStatus: Upgraded to cosmic on 2018-12-02 (18 days ago)
modified.conffile..etc.default.apport: [modified]
modified.conffile..etc.salt.roster: [modified]
mtime.conffile..etc.default.apport: 2014-11-26T20:33:01.966514
mtime.conffile..etc.salt.roster: 2018-07-26T00:31:37.371528

Revision history for this message
Iain Buclaw (iainb) wrote :
Revision history for this message
Iain Buclaw (iainb) wrote :

One possible cause might be the tornado package itself.

Upstream salt has the following dependency requirements.

---
tornado>=4.2.1,<6.0; python_version < '3'
tornado>=4.2.1,<5.0; python_version >= '3.4'
---

However the tornado package maintainer pushed the untested/unsupported version 5.0.2-1build1 into the cosmic release.

Revision history for this message
Iain Buclaw (iainb) wrote :

Having built and installed upstream packages (http://repo.saltstack.com/py3/ubuntu/18.04/amd64/latest/)

With the following changes.

---
diff -pur salt_2018.3.3+ds.orig/debian/control salt_2018.3.3+ds/debian/control
--- salt_2018.3.3+ds.orig/debian/control 2018-05-30 21:24:18.000000000 +0200
+++ salt_2018.3.3+ds/debian/control 2018-12-21 13:43:36.409794340 +0100
@@ -28,7 +28,7 @@ Depends: python3-apt,
          python3-msgpack (>= 0.4),
          python3-pkg-resources,
          python3-requests,
- python3-tornado (>= 4.2.1), python3-tornado (<< 5),
+ python3-tornado (>= 4.2.1), python3-tornado (<< 6),
          python3-yaml,
          python3-systemd,
          python3-psutil,
diff -pur salt_2018.3.3+ds.orig/debian/rules salt_2018.3.3+ds/debian/rules
--- salt_2018.3.3+ds.orig/debian/rules 2017-12-21 21:33:17.000000000 +0100
+++ salt_2018.3.3+ds/debian/rules 2018-12-21 13:44:07.311516770 +0100
@@ -28,3 +28,5 @@ override_dh_auto_build:
 ## dh_fixperms
 ## chmod 2750 debian/salt-common/var/log/salt
 ## chown root:adm debian/salt-common/var/log/salt
+
+override_dh_auto_test:
---

The running the program without arguments does not throw an exception, but neither does the program seem to be usable (that may be more due to botched build rather than anything else).

Revision history for this message
Benjamin Drung (bdrung) wrote :

Can you still reproduce it with salt 2018.3.4~git20180207+dfsg1-1 in Ubuntu 19.04?

Changed in salt (Ubuntu):
status: New → Incomplete
Changed in salt (Debian):
status: Unknown → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.