nim-lang / Nim

Nim is a statically typed compiled systems programming language. It combines successful concepts from mature languages like Python, Ada and Modula. Its design focuses on efficiency, expressiveness, and elegance (in that order of priority).

https://nim-lang.org

Other

16.54k stars 1.47k forks source link

Support OpenSSL 3 #19604

Closed FedericoCeratto closed 1 year ago

FedericoCeratto commented 2 years ago

OpenSSL 3 introduces many changes and removes various deprecated functions.

Announcement: https://www.openssl.org/blog/blog/2021/09/07/OpenSSL3.Final/ Migration guide: https://www.openssl.org/docs/man3.0/man7/migration_guide.html Partial list of missing symbols: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1006989

Another option would be to switch to a different library: https://en.wikipedia.org/wiki/Comparison_of_TLS_implementations

dom96 commented 2 years ago

I think ideally we want something that is pluggable and allows libraries to implement other SSL libraries.

Edit: re-reading my own message I think this is off-topic. I'll hide it.

arnetheduck commented 2 years ago

For reference, we use https://github.com/status-im/nim-bearssl which "just works" without dll:s etc as the C library gets built together with the nim code.

arnetheduck commented 2 years ago

When using a solution like that, it's also important that SSL support is separated from the std library distribution so as to allow critical security updates to happen on a different cadence.

FedericoCeratto commented 2 years ago

TLS support is part of the standard library. Of course the library implementing TLS is dynamically linked and can be updated independently from the Nim compiler and from the applications/libraries written in Nim.

Pluggable TLS implementations are discussed in #14719

FedericoCeratto commented 2 years ago

I'm preparing a PR. I hope people will be OK with dropping support for OpenSSL < 1.1.0 The 1.1.0 release train started on August 2016 Please feel free to vote this message thumbs up for dropping older versions or down otherwise.

FedericoCeratto commented 2 years ago

Additional datapoint: Python even dropped support for OpenSSL < 1.1.1 and does not support LibreSSL: https://peps.python.org/pep-0644/

ragingpastry commented 2 years ago

Ran into this when trying to use nimble on a vanilla nim:latest docker image

FedericoCeratto commented 2 years ago

Supporting OSX is more tricky than I expected as it needs to use the library shipped by brew. Also at the moment the tests are failing with an unclear error. Anybody willing to help?

Araq commented 2 years ago

As I've tried to tell you on discord, I get this error:

FAIL: tests/async/tasyncssl.nim c                                  ( 1.83 sec)
Test "tests/async/tasyncssl.nim" in category "async"
Failure: reExitcodesDiffer
Expected:
exitcode: 0

Gotten:
exitcode: 1

Output:
WARNING: nim/tests/async/tasyncssl is loading libcrypto in an unsafe way
No stack traceback available
SIGABRT: Abnormal termination.

I searched for the "in an unsafe way", but without much luck.

FedericoCeratto commented 2 years ago

Status update: This PR was partially reverted in https://github.com/nim-lang/Nim/pull/20341 and was not included in Nim 1.6.8

OpenSSL 3 has been released on Sep 7th, 2021 ( https://www.openssl.org/blog/blog/2021/09/07/OpenSSL3.Final/ ) and it's being adopted by various platforms ( https://repology.org/project/openssl/versions ) As such Nim cannot be shipped in the rolling/development version of Linux distributions including Debian, Ubuntu, openSUSE Tumbleweed etc.

tillea commented 2 years ago

I confirm that this issue of Nim has kicked a lot of packages from Debian testing. It would be really cool if this could be fixed soon. Thanks a lot, Andreas.

ghost commented 2 years ago

As such Nim cannot be shipped in the rolling/development version of Linux distributions including Debian, Ubuntu, openSUSE Tumbleweed etc.

While I understand your frustration and I support adding support for OpenSSL 3, right now almost no distributions ship with OpenSSL 3 only. Most Linux distros still ship with OpenSSL 1.1 by default - even Arch, openSUSE Tumbleweed. And distros like Debian Sid do ship with OpenSSL 3 by default, but they also have OpenSSL 1 in their repos, while Ubuntu is the only exception that doesn't do that.

hyperreal64 commented 2 years ago

While I understand your frustration and I support adding support for OpenSSL 3, right now almost no distributions ship with OpenSSL 3 only. Most Linux distros still ship with OpenSSL 1.1 by default - even Arch, openSUSE Tumbleweed. And distros like Debian Sid do ship with OpenSSL 3 by default, but they also have OpenSSL 1 in their repos, while Ubuntu is the only exception that doesn't do that.

Upcoming Fedora 37 release in October will deprecate openssl1.1 package. Even now, Fedora 36 uses OpenSSL 3 as default. https://fedoraproject.org/wiki/Releases/37/ChangeSet#Deprecate_openssl1.1_package

metagn commented 1 year ago

Hopefully resolved by #20668 and #20669 (for 1.6).

For the record #20341 did not remove openssl 3 support. It was opt-in with #19814 and kept that way, the default behavior was just made more biased toward older versions. It is no longer opt-in, it should now work by default along with other supported versions.

metagn commented 1 year ago

20669 was in 1.6.10 and 1.6.12 has been out for a while, as well as #20668 being in both release candidates for 2.0, I haven't seen any complaints about this, closing