[GH-ISSUE #2577] About OS that supports OpenSSL 3.x #1239

New issue

Open

opened 2026-03-04 01:52:28 +03:00 by kerem · 3 comments

kerem commented

2026-03-04 01:52:28 +03:00

Owner

Originally created by @ggtakec on GitHub (Oct 28, 2024).
Original GitHub issue: https://github.com/s3fs-fuse/s3fs-fuse/issues/2577

I would like to move s3fs' libcurl and encryption library to OpenSSL for the following OS versions.

The following OS versions support OpenSSL 3.x and can use OpenSSL.
- ubuntu:24.04
- ubuntu:22.04
- debian:bookworm(12)
- fedora:41
- fedora:40
- rockylinux:9
- alpine:3.20(3.19, 3.18)
For the following OS, you will need to use something other than OpenSSL(gnuTLS, NSS).
- ubuntu:20.04
- debian:bullseye(11)
- fedora:39
- rockylinux:8

@gaul
As for the code, gnuTLS, and NSS will remain, but in the future we will probably consolidate it into OpenSSL 3.x or later.

@juliogonzalez
Is it possible to divide the s3fs packages for each debian and RPM package into the above categories?
(Is SUSE's OpenSSL default set to 3.x?)

Originally created by @ggtakec on GitHub (Oct 28, 2024). Original GitHub issue: https://github.com/s3fs-fuse/s3fs-fuse/issues/2577 I would like to move s3fs' libcurl and encryption library to OpenSSL for the following OS versions. - The following OS versions support OpenSSL 3.x and can use OpenSSL. - ubuntu:24.04 - ubuntu:22.04 - debian:bookworm(12) - fedora:41 - fedora:40 - rockylinux:9 - alpine:3.20(3.19, 3.18) - For the following OS, you will need to use something other than OpenSSL(gnuTLS, NSS). - ubuntu:20.04 - debian:bullseye(11) - fedora:39 - rockylinux:8 @gaul As for the code, gnuTLS, and NSS will remain, but in the future we will probably consolidate it into OpenSSL 3.x or later. @juliogonzalez Is it possible to divide the s3fs packages for each debian and RPM package into the above categories? (Is SUSE's OpenSSL default set to 3.x?)

kerem added the

enhancement

label

2026-03-04 01:52:28 +03:00

kerem commented

2026-03-04 01:52:29 +03:00

Author

Owner

@gaul commented on GitHub (Oct 28, 2024):

Some references:

Debian bullseye (11) 1.1.1w-0+deb11u1
- EOL 2024-08-14
- LTS EOL 2026-08-31
Fedora 39 3.1.1-4.fc39
RHEL 8 (EPEL) openssl3-3.2.2-2.1
Ubuntu 20.04 1.1.1f-1ubuntu2.23
- LTS EOL 2025-04-23

Debian and Ubuntu don't package newer s3fs versions so we can drop support for them to reduce the maintenance burden.

But a broader question is why does s3fs support multiple SSL libraries? I believe on Fedora that the gnuTLS and libnss are just OpenSSL wrappers. It appears that Debian still uses gnuTLS so perhaps this is a packaging preference for them? macOS also uses gnuTLS. I don't know about NSS. This code doesn't change often but I broke support for them while doing some std::unique_ptr cleanup.

@gaul commented on GitHub (Oct 28, 2024): Some references: * Debian bullseye (11) [1.1.1w-0+deb11u1](https://packages.debian.org/bullseye/openssl) - EOL 2024-08-14 - LTS EOL 2026-08-31 * Fedora 39 [3.1.1-4.fc39](https://dl.fedoraproject.org/pub/fedora/linux/releases/39/Everything/x86_64/os/Packages/o/) * RHEL 8 (EPEL) [openssl3-3.2.2-2.1](https://dl.fedoraproject.org/pub/epel/8/Everything/x86_64/Packages/o/) * Ubuntu 20.04 [1.1.1f-1ubuntu2.23](https://packages.ubuntu.com/focal/openssl) - LTS EOL 2025-04-23 Debian and Ubuntu don't package newer s3fs versions so we can drop support for them to reduce the maintenance burden. But a broader question is why does s3fs support multiple SSL libraries? I believe on Fedora that the gnuTLS and libnss are just OpenSSL wrappers. It appears that [Debian still uses gnuTLS](https://packages.debian.org/trixie/s3fs) so perhaps this is a packaging preference for them? [macOS also uses gnuTLS](https://github.com/gromgit/homebrew-fuse/blob/main/Formula/s3fs-mac.rb). I don't know about NSS. This code doesn't change often but I broke support for them while doing some `std::unique_ptr` cleanup.

kerem commented

2026-03-04 01:52:29 +03:00

Author

Owner

@juliogonzalez commented on GitHub (Oct 28, 2024):

rockylinux:8

It's available via EPEL8 (3.2.2)... and since s3fs is shipped via EPEL8, it should be fine.

The only thing to care about is that people building from sources know that they need to enable EPEL.

@juliogonzalez Is it possible to divide the s3fs packages for each debian and RPM package into the above categories? (Is SUSE's OpenSSL default set to 3.x?)

openSUSE Leap 15.6 and newer (Tumbleweed/MicroOS): yes. available and by used by default.
SUSE Linux Enterprise 12: Not default, and not available
SUSE Linux Enterprise 15: Only available starting with SP4. On SP4 and SP5 it's not the default. SP6 and newer have openSSL3 as default
Newer SUSE Linux versions: openSSL3 is always available, and I think it's the default as well (can't check right now).

Debian and Ubuntu don't package newer s3fs versions so we can drop support for them to reduce the maintenance burden.

I guess you mean old Debian and Ubuntu versions? Leaving Debian11 and Ubuntu 20.04 behind should be OK, if it's announced and keeping openSSL2 is not desired.

Keep in mind that even if they don't package it officially, that doesn't mean people is not using it by building it on their own. I even provide the package via Open Build Service when Debian Unstable packages the new versions (I need to check soon if they did already), as Debian includes new versions in the next Stable versions.

@juliogonzalez commented on GitHub (Oct 28, 2024): > rockylinux:8 It's available via EPEL8 (`3.2.2`)... and since s3fs is shipped via EPEL8, it should be fine. The only thing to care about is that people building from sources know that they need to enable EPEL. > @juliogonzalez Is it possible to divide the s3fs packages for each debian and RPM package into the above categories? (Is SUSE's OpenSSL default set to 3.x?) - openSUSE Leap 15.6 and newer (Tumbleweed/MicroOS): yes. available and by used by default. - SUSE Linux Enterprise 12: Not default, and not available - SUSE Linux Enterprise 15: Only available starting with [SP4](https://www.suse.com/releasenotes/x86_64/SUSE-SLES/15-SP4/index.html#jsc-SLE-21421). On SP4 and SP5 it's not the default. [SP6 and newer have openSSL3 as default](https://www.suse.com/releasenotes/x86_64/SUSE-SLES/15-SP6/index.html#bsc-1220091) - Newer SUSE Linux versions: openSSL3 is always available, and I think it's the default as well (can't check right now). > Debian and Ubuntu don't package newer s3fs versions so we can drop support for them to reduce the maintenance burden. I guess you mean old Debian and Ubuntu versions? Leaving Debian11 and Ubuntu 20.04 behind should be OK, if it's announced and keeping openSSL2 is not desired. Keep in mind that even if they don't package it officially, that doesn't mean people is not using it by building it on their own. I even provide the package via Open Build Service when Debian Unstable packages the new versions (I need to check soon if they did already), as Debian includes new versions in the next Stable versions.

kerem commented

2026-03-04 01:52:29 +03:00

Author

Owner

@ggtakec commented on GitHub (Oct 28, 2024):

The reason s3fs supports NSS and gnuTLS is due to the OpenSSL license issue.
Not only does s3fs depend on libcurl, but it also uses crypt library for tokens, so this license issue had to be taken into consideration.

From OpenSSL 3.x onwards, the license was changed to Apache, and it can be freely distributed including the source code, but before that there were issues with distributing the source code.
When distributing packages for each OS, the source code package is distributed, so this was a concern.
(For example, curl (libcurl) seems to be struggling in the same way.)

@ggtakec commented on GitHub (Oct 28, 2024): The reason s3fs supports NSS and gnuTLS is due to the OpenSSL license issue. Not only does s3fs depend on libcurl, but it also uses crypt library for tokens, so this license issue had to be taken into consideration. From OpenSSL 3.x onwards, the license was changed to Apache, and it can be freely distributed including the source code, but before that there were issues with distributing the source code. When distributing packages for each OS, the source code package is distributed, so this was a concern. (For example, curl (libcurl) seems to be struggling in the same way.)