Recent searches

No recent searches

Search options

Only available when logged in.
med-mastodon.com is one of the many independent Mastodon servers you can use to participate in the fediverse.
Medical community on Mastodon

Administered by:

Server stats:

310
active users

med-mastodon.com: AboutProfiles directoryPrivacy policy

Mastodon: AboutGet the appKeyboard shortcutsView source codev4.5.0

#libressl

0 posts0 participants0 posts today
Peter N. M. Hansteen<p>LibreSSL 4.1.2 and 4.2.1 released <a href="https://www.undeadly.org/cgi?action=article;sid=20251102090208" rel="nofollow noopener" translate="no" target="_blank"><span class="invisible">https://www.</span><span class="ellipsis">undeadly.org/cgi?action=articl</span><span class="invisible">e;sid=20251102090208</span></a> <a href="https://mastodon.social/tags/openbsd" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>openbsd</span></a> <a href="https://mastodon.social/tags/libressl" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>libressl</span></a> <a href="https://mastodon.social/tags/tls" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>tls</span></a> <a href="https://mastodon.social/tags/ssl" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>ssl</span></a> <a href="https://mastodon.social/tags/security" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>security</span></a> <a href="https://mastodon.social/tags/networking" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>networking</span></a> <a href="https://mastodon.social/tags/cryptography" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>cryptography</span></a> <a href="https://mastodon.social/tags/crypto" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>crypto</span></a> <a href="https://mastodon.social/tags/realcrypto" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>realcrypto</span></a> <a href="https://mastodon.social/tags/libresoftware" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>libresoftware</span></a> <a href="https://mastodon.social/tags/freesoftware" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>freesoftware</span></a></p>
Bryan Steele :flan_beard:<p><a href="https://bsd.network/tags/LibreSSL" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>LibreSSL</span></a> 4.2.0 "blazeit" released today*</p><p><a href="https://cdn.openbsd.org/pub/OpenBSD/LibreSSL/libressl-4.2.0-relnotes.txt" rel="nofollow noopener" target="_blank"><span class="invisible">https://</span><span class="ellipsis">cdn.openbsd.org/pub/OpenBSD/Li</span><span class="invisible">breSSL/libressl-4.2.0-relnotes.txt</span></a></p><p>* LibreSSL releases have no codenames, officially. :flan_coffee:​</p>
Peter N. M. Hansteen<p>LibreSSL 4.1.1 and 4.0.1 released <a href="https://www.undeadly.org/cgi?action=article;sid=20251002054519" rel="nofollow noopener" translate="no" target="_blank"><span class="invisible">https://www.</span><span class="ellipsis">undeadly.org/cgi?action=articl</span><span class="invisible">e;sid=20251002054519</span></a> <a href="https://mastodon.social/tags/openbsd" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>openbsd</span></a> <a href="https://mastodon.social/tags/libressl" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>libressl</span></a> <a href="https://mastodon.social/tags/tls" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>tls</span></a> <a href="https://mastodon.social/tags/https" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>https</span></a> <a href="https://mastodon.social/tags/cryptography" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>cryptography</span></a> <a href="https://mastodon.social/tags/security" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>security</span></a> <a href="https://mastodon.social/tags/newrelease" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>newrelease</span></a> <a href="https://mastodon.social/tags/development" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>development</span></a> <a href="https://mastodon.social/tags/freesoftware" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>freesoftware</span></a> <a href="https://mastodon.social/tags/libresoftware" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>libresoftware</span></a></p>
Felix Palmen :freebsd: :c64:<p>Oh boy, I have a lead! And it's NOT related to <a href="https://mastodon.bsd.cafe/tags/TLS" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>TLS</span></a>. I finally noticed another pattern: <a href="https://mastodon.bsd.cafe/tags/swad" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>swad</span></a> only <a href="https://mastodon.bsd.cafe/tags/crashed" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>crashed</span></a> when running as a <a href="https://mastodon.bsd.cafe/tags/daemon" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>daemon</span></a>. The daemonizing wasn't the problem, but the default logging configuration attached to it: "fake async", by letting a <a href="https://mastodon.bsd.cafe/tags/threadpool" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>threadpool</span></a> job do the logging.</p><p>Forcing THAT even when running in foreground, I can finally reproduce a crash. And I wouldn't be surprised if that was actually the reason for crashing "pretty quickly" with <a href="https://mastodon.bsd.cafe/tags/LibreSSL" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>LibreSSL</span></a> (and only rarely with <a href="https://mastodon.bsd.cafe/tags/OpenSSL" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>OpenSSL</span></a>), I mean, something going rogue in your address space can have the weirdest effects.</p>
Felix Palmen :freebsd: :c64:<p>For two days straight, I just can't reproduce <a href="https://mastodon.bsd.cafe/tags/swad" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>swad</span></a> <a href="https://mastodon.bsd.cafe/tags/crashing" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>crashing</span></a> with *anything* in place (<a href="https://mastodon.bsd.cafe/tags/clang" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>clang</span></a> <a href="https://mastodon.bsd.cafe/tags/sanitizer" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>sanitizer</span></a> instrumentation, attached <a href="https://mastodon.bsd.cafe/tags/debugger" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>debugger</span></a> like <a href="https://mastodon.bsd.cafe/tags/lldb" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>lldb</span></a>) that could give me the slightest hint what's going wrong. 😡</p><p>But it *does* crash when "unobserved". And it looks like this is happening a lot sooner (or, more often?) when using <a href="https://mastodon.bsd.cafe/tags/LibreSSL" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>LibreSSL</span></a> ... but I also suspect this could be a red herring in the end.</p><p>Situation reminds me of my physics teacher back at school, who used to say something in german I just can't ever forget:</p><p>"Wer misst, misst Mist."</p><p>Feeble attempt in english would be "the one who measures measures crap", it was his humorous way to bring one consequence of <a href="https://mastodon.bsd.cafe/tags/Heisenberg" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>Heisenberg</span></a>'s indeterminacy principle to the point. And indeed, <a href="https://mastodon.bsd.cafe/tags/debugging" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>debugging</span></a> computer programs always suffers from similar problems...</p>
Felix Palmen :freebsd: :c64:<p>I need help. First the question: On <a href="https://mastodon.bsd.cafe/tags/FreeBSD" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>FreeBSD</span></a>, with all ports built with <a href="https://mastodon.bsd.cafe/tags/LibreSSL" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>LibreSSL</span></a>, can I somehow use the <a href="https://mastodon.bsd.cafe/tags/clang" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>clang</span></a> <a href="https://mastodon.bsd.cafe/tags/thread" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>thread</span></a> <a href="https://mastodon.bsd.cafe/tags/sanitizer" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>sanitizer</span></a> on a binary actually using LibreSSL and get sane output?</p><p>What I now observe debugging <a href="https://mastodon.bsd.cafe/tags/swad" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>swad</span></a>:</p><p>- A version built with <a href="https://mastodon.bsd.cafe/tags/OpenSSL" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>OpenSSL</span></a> (from base) doesn't crash. At least I tried very hard, really stressing it with <a href="https://mastodon.bsd.cafe/tags/jmeter" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>jmeter</span></a>, to no avail. Built with LibreSSL, it does crash.<br>- Less relevant: the OpenSSL version also performs slightly better, but needs almost twice the RAM<br>- The thread sanitizer finds nothing to complain when built with OpenSSL<br>- It complains a lot with LibreSSL, but the reports look "fishy", e.g. it seems to intercept some OpenSSL API functions (like SHA384_Final)<br>- It even complains when running with a single-thread event loop.<br>- 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.<br>- I can't imagine doing that on a *single* thread could break with LibreSSL, I mean, this would make SSL_CTX pretty much pointless<br>- 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 😳</p>
Felix Palmen :freebsd: :c64:<p>More interesting progress trying to make <a href="https://mastodon.bsd.cafe/tags/swad" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>swad</span></a> suitable for very busy sites!</p><p>I realized that <a href="https://mastodon.bsd.cafe/tags/TLS" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>TLS</span></a> (both with <a href="https://mastodon.bsd.cafe/tags/OpenSSL" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>OpenSSL</span></a> and <a href="https://mastodon.bsd.cafe/tags/LibreSSL" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>LibreSSL</span></a>) 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 <a href="https://mastodon.bsd.cafe/tags/lockfree" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>lockfree</span></a> queue as opposed to one protected by a <a href="https://mastodon.bsd.cafe/tags/mutex" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>mutex</span></a>. 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. 😆</p><p>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.</p><p>Open issue: Can I do something about TLS? There *must* be some way to make it perform at least a *bit* better...</p><p>(*) 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: <a href="https://dl.acm.org/doi/10.1145/248052.248106" rel="nofollow noopener" translate="no" target="_blank"><span class="invisible">https://</span><span class="ellipsis">dl.acm.org/doi/10.1145/248052.</span><span class="invisible">248106</span></a></p>
Kevin Karhan :verified:<p><span class="h-card" translate="no"><a href="https://mastodon.net2o.de/@forthy42" class="u-url mention" rel="nofollow noopener" target="_blank">@<span>forthy42</span></a></span> doof nur dass es keine Alternativen abselts von <a href="https://infosec.space/tags/OpenSSL" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>OpenSSL</span></a>, <a href="https://infosec.space/tags/LibreSSL" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>LibreSSL</span></a> &amp; <a href="https://infosec.space/tags/NSS" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>NSS</span></a> gibt - und wer <a href="https://infosec.space/tags/PCIDSS" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>PCIDSS</span></a> erfüllen muss, ist auf zertifizierte Binaries angewiesen!</p>
Klaus Frank<p><span class="h-card" translate="no"><a href="https://mastodon.social/@hanno" class="u-url mention" rel="nofollow noopener" target="_blank">@<span>hanno</span></a></span> Speaking of <a href="https://chaos.social/tags/OpenSSL" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>OpenSSL</span></a>, what's the state of <a href="https://chaos.social/tags/LibreSSL" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>LibreSSL</span></a>, did that manage to get some traction or did it die out? Didn't really hear much about it for a long while now.</p>
Felix Palmen :freebsd: :c64:<p>Released: <a href="https://mastodon.bsd.cafe/tags/swad" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>swad</span></a> v0.1 🥳 </p><p>Looking for a simple way to add <a href="https://mastodon.bsd.cafe/tags/authentication" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>authentication</span></a> to your <a href="https://mastodon.bsd.cafe/tags/nginx" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>nginx</span></a> reverse proxy? Then swad *could* be for you!</p><p>swad is the "Simple Web Authentication Daemon", written in pure <a href="https://mastodon.bsd.cafe/tags/C" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>C</span></a> (+ <a href="https://mastodon.bsd.cafe/tags/POSIX" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>POSIX</span></a>) with almost no external dependencies. <a href="https://mastodon.bsd.cafe/tags/TLS" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>TLS</span></a> support requires <a href="https://mastodon.bsd.cafe/tags/OpenSSL" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>OpenSSL</span></a> (or <a href="https://mastodon.bsd.cafe/tags/LibreSSL" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>LibreSSL</span></a>). It's designed to work with nginx' "auth_request" module and offers authentication using a <a href="https://mastodon.bsd.cafe/tags/cookie" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>cookie</span></a> and a login form.</p><p>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: <a href="https://mastodon.bsd.cafe/tags/PAM" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>PAM</span></a>. But as pam already allows pretty flexible configuration, I already consider this pretty useful 🙈</p><p>If you want to know more, read here:<br><a href="https://github.com/Zirias/swad" rel="nofollow noopener" translate="no" target="_blank"><span class="invisible">https://</span><span class="">github.com/Zirias/swad</span><span class="invisible"></span></a></p>
jan Anja();<p>I can't count how many times I've put <code>import requests</code> behind a warnings filter after urllib3's developers decided they can dictate what libraries the end user has.</p><p><a href="https://github.com/urllib3/urllib3/issues/3020" rel="nofollow noopener" translate="no" target="_blank"><span class="invisible">https://</span><span class="ellipsis">github.com/urllib3/urllib3/iss</span><span class="invisible">ues/3020</span></a></p><p><a href="https://wetdry.world/tags/Python" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>Python</span></a> <a href="https://wetdry.world/tags/Requests" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>Requests</span></a> <a href="https://wetdry.world/tags/Urllib3" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>Urllib3</span></a> <a href="https://wetdry.world/tags/OpenSSL" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>OpenSSL</span></a> <a href="https://wetdry.world/tags/LibreSSL" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>LibreSSL</span></a></p>
Bryan Steele :flan_beard:<p><a href="https://x.com/openbsd/status/1889330772399501381" rel="nofollow noopener" target="_blank"><span class="invisible">https://</span><span class="ellipsis">x.com/openbsd/status/188933077</span><span class="invisible">2399501381</span></a></p><blockquote><p>LibreSSL is not affected by the OpenSSL vulnerabilities announced today.</p></blockquote><p><a href="https://bsd.network/tags/openbsd" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>openbsd</span></a> <a href="https://bsd.network/tags/libressl" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>libressl</span></a> <a href="https://bsd.network/tags/openssl" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>openssl</span></a></p>
Rafael Sadowski<p>Big performance win in <a href="https://bsd.network/tags/LibreSSL" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>LibreSSL</span></a> 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! <a href="https://marc.info/?l=openbsd-cvs&amp;m=173900927421446&amp;w=2" rel="nofollow noopener" target="_blank"><span class="invisible">https://</span><span class="ellipsis">marc.info/?l=openbsd-cvs&amp;m=173</span><span class="invisible">900927421446&amp;w=2</span></a></p>
ティージェーグレェNice! <span class="h-card"><a href="https://chaos.social/users/neverpanic" class="u-url mention" rel="nofollow noopener" target="_blank">@neverpanic@chaos.social</a></span> just merged a Pull Request (specifically <a href="https://github.com/macports/macports-ports/pull/26827" rel="nofollow noopener" target="_blank">https://github.com/macports/macports-ports/pull/26827)</a> that supposedly fixes building LibreSSL on some older versions of OS X?<br><br>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.<br><br>Here's hoping the Port Health for LibreSSL improves!<br><br>(screenshot of the current Port Health for future reference attached)<br><br><a href="https://snac.bsd.cafe?t=macports" class="mention hashtag" rel="nofollow noopener" target="_blank">#MacPorts</a> <a href="https://snac.bsd.cafe?t=libressl" class="mention hashtag" rel="nofollow noopener" target="_blank">#LibreSSL</a> <a href="https://snac.bsd.cafe?t=tls" class="mention hashtag" rel="nofollow noopener" target="_blank">#TLS</a> <a href="https://snac.bsd.cafe?t=macos" class="mention hashtag" rel="nofollow noopener" target="_blank">#macOS</a> <a href="https://snac.bsd.cafe?t=osx" class="mention hashtag" rel="nofollow noopener" target="_blank">#OSX</a> <a href="https://snac.bsd.cafe?t=openssl" class="mention hashtag" rel="nofollow noopener" target="_blank">#OpenSSL</a> <a href="https://snac.bsd.cafe?t=opensource" class="mention hashtag" rel="nofollow noopener" target="_blank">#OpenSource</a><br>
R. L. Dane :Debian:<p>Dear Python,</p><p>It would be so great if you'd stop warning me that I'm using <a href="https://alpha.polymaths.social/tags/libressl" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>LibreSSL</span></a> (on <a href="https://alpha.polymaths.social/tags/openbsd" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>OpenBSD</span></a>).</p><p>The whole point is to not have the entire world using a single library for all encryption.<br>That would not be enviable.</p><pre><code>.../.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( </code></pre>
Replied in thread
Felix Palmen :freebsd: :c64:

@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 from with , 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 and wrote about it a few years ago here:
sekrit.de/webdocs/freebsd/advo

sekrit.deAdvocacy: Why I personally prefer FreeBSD over Linux
*
Felix Palmen :freebsd: :c64:

Finally a bulk build of my package list succeeded for 14.1. Quite some fallout to fix (I still refuse to use OpenSSL ...) ... and a few other mysterious issues.

Testing it on my desktop right now. 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

Bryan Steele :flan_beard:

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 in -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@

cvsweb.openbsd.org/cgi-bin/cvs

uses an explicit list of symbols exported to help avoid unintentional namespace pollution for a number of base libraries, starting with libc in 2015.

marc.info/?l=openbsd-cvs&m=144

TrendingLive feeds
About