skyjake / lagrange

A Beautiful Gemini Client
https://gmi.skyjake.fi/lagrange/
BSD 2-Clause "Simplified" License
1.19k stars 62 forks source link

Use LibreSSL instead of OpenSSL #554

Open hardBSDk opened 1 year ago

hardBSDk commented 1 year ago

After Heartbleed event, the OpenSSL project lost credibility in relation to code security measures (memory-safety).

Forks were created and LibreSSL/BoringSSL came, with better code security measures.

LibreSSL use the same APIs of OpenSSL, rebase with mainstream OpenSSL and clean obsolete code/ciphers/algorithms.

CyberTailor commented 1 year ago

I can confirm that Lagrage works fine with LibreSSL, there's no need to change anything

hardBSDk commented 1 year ago

I can confirm that Lagrage works fine with LibreSSL, there's no need to change anything

My request is to change the default library of the compilation/pre-compiled binaries.

skyjake commented 1 year ago

I looked into this a bit. While LibreSSL had a good start with modernizing and cleaning things up, OpenSSL has since evolved significantly. I don't see a pressing need for changes here, especially with Linux distros not being very interested in LibreSSL.

I will switch the macOS prebuilt libraries to LibreSSL since that's what Apple prefers to use.

On Windows I'm using MSYS2, but they don't provide binaries for LibreSSL. I attempted to build it myself but the build scripts didn't work for me under MSYS. I will keep using OpenSSL for the Windows binaries.

The x86_64 Linux AppImage is built on Ubuntu 18.04. It might make sense to try to manually compile the latest LibreSSL and use it instead of the system-provided libssl/libcrypto. I'll leave this for another day.

The armhf Linux AppImage is built on Raspbian 10 (Buster), and it's pretty much the same story as with Ubuntu 18.

On *BSD, one is free to build the app with LibreSSL if they want. I'm not sure if the CMakeLists needs any changes (?).

skyjake commented 1 year ago

default library of the compilation

@hardBSDk From a compilation point of view, LibreSSL is usually a drop-in replacement for OpenSSL. It is up to whoever is doing the build to point CMake to the appropriate "openssl" pkg-config files via the PKG_CONFIG_PATH environment variable.

skyjake commented 1 year ago

When I get a chance, I will boot up my OpenBSD and FreeBSD VMs and check the build config with LibreSSL.

skyjake commented 1 year ago

v1.14.2 includes the changes from the previous comment.

skyjake commented 1 year ago

I don't currently plan to make further changes regarding LibreSSL, so closing this (at least for now).

skyjake commented 1 year ago

Reopening to investigate some macOS LibreSSL issues:

v1.15.0 will revert and go back to OpenSSL, at least for now.

jrmarino commented 1 week ago

by they way, lagrange doesn't even build with the latest openssl. I confirmed it builds with the EOL openssl 1.1.1, but using openssl 3.3.2 I get this (first bit, there are many many more reference errors)

/raven/toolchain/bin/ld: CMakeFiles/app.dir/src/app.c.o: in function `updateCACertificates_App.part.0':
app.c:(.text+0x12ec): undefined reference to `setCACertificates_TlsRequest'
/raven/toolchain/bin/ld: CMakeFiles/app.dir/src/app.c.o: in function `init_App_.constprop.0':
app.c:(.text+0xb7f7): undefined reference to `setCACertificates_TlsRequest'
/raven/toolchain/bin/ld: CMakeFiles/app.dir/src/app.c.o: in function `updateCACertificates_App':
app.c:(.text+0x142e): undefined reference to `setCACertificates_TlsRequest'
/raven/toolchain/bin/ld: CMakeFiles/app.dir/src/gmrequest.c.o: in function `checkServerCertificate_GmRequest_':
gmrequest.c:(.text+0x842): undefined reference to `serverCertificate_TlsRequest'
/raven/toolchain/bin/ld: gmrequest.c:(.text+0x86a): undefined reference to `address_TlsRequest'
/raven/toolchain/bin/ld: gmrequest.c:(.text+0x89a): undefined reference to `address_TlsRequest'
/raven/toolchain/bin/ld: gmrequest.c:(.text+0x8b2): undefined reference to `publicKeyFingerprint_TlsCertificate'
/raven/toolchain/bin/ld: gmrequest.c:(.text+0x8d7): undefined reference to `isExpired_TlsCertificate'
/raven/toolchain/bin/ld: gmrequest.c:(.text+0x91c): undefined reference to `verify_TlsCertificate'
/raven/toolchain/bin/ld: gmrequest.c:(.text+0x92d): undefined reference to `validUntil_TlsCertificate'

so even if libressl isn't supported, the openssl support could / should be better. I want to purge openssl 1.1.1 since it's no longer getting public security updates and I don't want to have to support an older version of openssl (e.g. 3.0) for a single s/w like lagrange.

skyjake commented 1 week ago

lagrange doesn't even build with the latest openssl

Hmm, it builds fine for me using OpenSSL 3.3.2, at least using the dev branch. Did you try doing a clean build from scratch?

jrmarino commented 1 week ago

yes, I was just coming back. I found a patch that had openssl11 hardcoded it in. It was my fault. openssl 3.3.2 works for me as well.

edited: if curious, the first part of the patch is here:

--- build-tui.sh.orig   2023-12-04 13:15:21 UTC
+++ build-tui.sh
@@ -14,25 +14,15 @@
 #
 # You can customize the install directory prefix here and build type here:

-INSTALL_PREFIX="/usr/local"
+INSTALL_PREFIX="__PREFIX__"
 CMAKE_BUILD_TYPE="Release"
+export PKG_CONFIG_PATH=/__PREFIX__/openssl30/lib/pkgconfig
+export LDFLAGS="-L/__PREFIX__/openssl30/lib -Wl,-rpath,/__PREFIX__/openssl30/lib"

 echo "\nThis script will build and optionally install clagrange with"
 echo "statically linked the_Foundation and SEALCurses. First, let's configure"
 echo "the build.\n"