#libressl
#LibreSSL 4.2.0 "blazeit" released today*
https://cdn.openbsd.org/pub/OpenBSD/LibreSSL/libressl-4.2.0-relnotes.txt
* LibreSSL releases have no codenames, officially. 
I need help. First the question: On #FreeBSD, with all ports built with #LibreSSL, can I somehow use the #clang #thread #sanitizer on a binary actually using LibreSSL and get sane output?
What I now observe debugging #swad:
- A version built with #OpenSSL (from base) doesn't crash. At least I tried very hard, really stressing it with #jmeter, to no avail. Built with LibreSSL, it does crash.
- Less relevant: the OpenSSL version also performs slightly better, but needs almost twice the RAM
- The thread sanitizer finds nothing to complain when built with OpenSSL
- It complains a lot with LibreSSL, but the reports look "fishy", e.g. it seems to intercept some OpenSSL API functions (like SHA384_Final)
- It even complains when running with a single-thread event loop.
- I use a single SSL_CTX per listening socket, creating SSL objects from it per connection ... also with multithreading; according to a few sources, this should be supported and safe.
- I can't imagine doing that on a *single* thread could break with LibreSSL, I mean, this would make SSL_CTX pretty much pointless
- I *could* imagine sharing the SSL_CTX with multiple threads to create their SSL objects from *might* not be safe with LibreSSL, but no idea how to verify as long as the thread sanitizer gives me "delusional" output 
More interesting progress trying to make #swad suitable for very busy sites!
I realized that #TLS (both with #OpenSSL and #LibreSSL) is a *major* bottleneck. With TLS enabled, I couldn't cross 3000 requests per second, with somewhat acceptable response times (most below 500ms). Disabling TLS, I could really see the impact of a #lockfree queue as opposed to one protected by a #mutex. With the mutex, up to around 8000 req/s could be reached on the same hardware. And with a lockfree design, that quickly went beyond 10k req/s, but crashed. 
So I read some scientific papers 
... and redesigned a lot (*). And now it finally seems to work. My latest test reached a throughput of almost 25k req/s, with response times below 10ms for most requests! I really didn't expect to see *this* happen. 
Maybe it could do even more, didn't try yet.
Open issue: Can I do something about TLS? There *must* be some way to make it perform at least a *bit* better...
(*) edit: Here's the design I finally used, with a much simplified "dequeue" because the queues in question are guaranteed to have only a single consumer: https://dl.acm.org/doi/10.1145/248052.248106
Released: #swad v0.1 
Looking for a simple way to add #authentication to your #nginx reverse proxy? Then swad *could* be for you!
swad is the "Simple Web Authentication Daemon", written in pure #C (+ #POSIX) with almost no external dependencies. #TLS support requires #OpenSSL (or #LibreSSL). It's designed to work with nginx' "auth_request" module and offers authentication using a #cookie and a login form.
Well, this is a first release and you can tell by the version number it isn't "complete" yet. Most notably, only one single credentials checker is implemented: #PAM. But as pam already allows pretty flexible configuration, I already consider this pretty useful
If you want to know more, read here:
https://github.com/Zirias/swad
Recent and not so recent changes in OpenBSD that make life better (and may turn up elsewhere too) https://nxdomain.no/~peter/blogposts/recent-and-not-so-recent_changes_in_openbsd_that_make_life_better.html from 2021 but has aged surprisingly well #openbsd #freesoftware #libresoftware #libressl #ssh #pf #laptops
https://x.com/openbsd/status/1889330772399501381
LibreSSL is not affected by the OpenSSL vulnerabilities announced today.
Big performance win in #LibreSSL thanks to tb@! CRLs are now cached in the issuer cache, reducing redundant signature verification. This speeds up workloads like rpki-client, where a single (CA, CRL) pair could eat 20-25% of runtime—now 10x faster! https://marc.info/?l=openbsd-cvs&m=173900927421446&w=2
Since my car was broken into and two laptops were stolen in August earlier this year, I no longer have the 2012 MacBook Pro I was using to test on older OS X versions.
Here's hoping the Port Health for LibreSSL improves!
(screenshot of the current Port Health for future reference attached)
#MacPorts #LibreSSL #TLS #macOS #OSX #OpenSSL #OpenSource
Dear Python,
It would be so great if you'd stop warning me that I'm using #LibreSSL (on #OpenBSD).
The whole point is to not have the entire world using a single library for all encryption.
That would not be enviable.
.../.local/pipx/venvs/sncli/lib/python3.11/site-packages/urllib3/__init__.py:35: NotOpenSSLWarning: urllib3 v2 only supports OpenSSL 1.1.1+, currently the 'ssl' module is compiled with 'LibreSSL 4.0.0'. See: https://github.com/urllib3/urllib3/issues/3020
warnings.warn(
GitHub Actions Continuous Integration checks went OK!
I don't have commit access, so it's up to someone else to merge it.
Nice to see, at least locally:
% ssh -V
OpenSSH_9.9p1, LibreSSL 4.0.0
#LibreSSL #MacPorts #OpenSource #TLS #OpenBSD #macOS #SSL #Security #QUIC #Cryptography #HTTPS
@profoundlynerdy The major BSD flavors all offer both, repositories with binary packages and a "ports" tree enabling to easily build locally (which is also used for building the packages). The vast majority of users should probably opt for the binary packages. Building yourself only makes sense if you really want non-default build options (e.g. I use #LibreSSL from #OpenBSD with #FreeBSD, where it's available as a port ... to actually use that, all ports must be built with LibreSSL instead of OpenSSL).
I personally like FreeBSD much better than #Linux and wrote about it a few years ago here:
https://sekrit.de/webdocs/freebsd/advocacy.html
Finally a #poudriere bulk build of my package list succeeded for #FreeBSD 14.1. Quite some #libressl fallout to fix (I still refuse to use OpenSSL ...) ... and a few other mysterious issues.
Testing it on my desktop right now. #ZFS #bootenvironments are still AWESOME! Did just the following:
# bectl create new
# bectl mount new /mnt/tmp
# cd /usr/src
# make BATCH_DELETE_OLD_FILES=yes DESTDIR=/mnt/tmp installkernel installworld delete-old delete-old-libs
# etcupdate -D /mnt/tmp
# etcupdate resolve -D /mnt/tmp
# pkg -c /mnt/tmp upgrade -f
# pkg -c /mnt/tmp autoremove
# bectl umount new
# bectl activate -t new
Full upgrade without touching the running installation, one single reboot to test it! Yes, for a major upgrade, running was FreeBSD 13.3 
Finishing up some longstanding work started in 2022, Bob Beck committed a patch enabling namespaced (symbol hiding) builds by default for libssl and libcrypto for #LibreSSL in #OpenBSD -current.
beck@ modified src/lib/libcrypto/Makefile: Enable namespaced builds by default for libssl and libcrypto.
Some further refinements will happen to the build process to automatically generate the Symbols.namespace file, and to remove our last public unhidden symbol (which was a mistake, but waits for a major bump to get removed)
But for now everything should be using this.
ok tb@
In addition to a flurry of commits over the years hiding symbols, the initial commit notes:
Fully explained in libcrypto/README. TL;DR make sure libcrypto and libssl's function calls internally and to each other are via symbol names that won't get overridden by linking other libraries.
Mostly work by guenther@, which will currently be gated behind a build setting NAMESPACE=yes. once we convert all the symbols to his method we will do a major bump and pick up the changes.
ok tb@ jsing@
#OpenBSD uses an explicit list of symbols exported to help avoid unintentional namespace pollution for a number of base libraries, starting with libc in 2015.