Fosstodon

Felix Palmen :freebsd: :c64: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">#TLS</a>. I finally noticed another pattern: <a href="https://mastodon.bsd.cafe/tags/swad" class="mention hashtag" rel="nofollow noopener" target="_blank">#swad</a> only <a href="https://mastodon.bsd.cafe/tags/crashed" class="mention hashtag" rel="nofollow noopener" target="_blank">#crashed</a> when running as a <a href="https://mastodon.bsd.cafe/tags/daemon" class="mention hashtag" rel="nofollow noopener" target="_blank">#daemon</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">#threadpool</a> job do the logging.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">#LibreSSL</a> (and only rarely with <a href="https://mastodon.bsd.cafe/tags/OpenSSL" class="mention hashtag" rel="nofollow noopener" target="_blank">#OpenSSL</a>), I mean, something going rogue in your address space can have the weirdest effects.

Felix Palmen :freebsd: :c64: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">#swad</a> <a href="https://mastodon.bsd.cafe/tags/crashing" class="mention hashtag" rel="nofollow noopener" target="_blank">#crashing</a> with *anything* in place (<a href="https://mastodon.bsd.cafe/tags/clang" class="mention hashtag" rel="nofollow noopener" target="_blank">#clang</a> <a href="https://mastodon.bsd.cafe/tags/sanitizer" class="mention hashtag" rel="nofollow noopener" target="_blank">#sanitizer</a> instrumentation, attached <a href="https://mastodon.bsd.cafe/tags/debugger" class="mention hashtag" rel="nofollow noopener" target="_blank">#debugger</a> like <a href="https://mastodon.bsd.cafe/tags/lldb" class="mention hashtag" rel="nofollow noopener" target="_blank">#lldb</a>) that could give me the slightest hint what's going wrong. 😡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">#LibreSSL</a> ... but I also suspect this could be a red herring in the end.Situation reminds me of my physics teacher back at school, who used to say something in german I just can't ever forget:"Wer misst, misst Mist."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">#Heisenberg</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">#debugging</a> computer programs always suffers from similar problems...

Felix Palmen :freebsd: :c64:I need help. First the question: On <a href="https://mastodon.bsd.cafe/tags/FreeBSD" class="mention hashtag" rel="nofollow noopener" target="_blank">#FreeBSD</a>, with all ports built with <a href="https://mastodon.bsd.cafe/tags/LibreSSL" class="mention hashtag" rel="nofollow noopener" target="_blank">#LibreSSL</a>, can I somehow use the <a href="https://mastodon.bsd.cafe/tags/clang" class="mention hashtag" rel="nofollow noopener" target="_blank">#clang</a> <a href="https://mastodon.bsd.cafe/tags/thread" class="mention hashtag" rel="nofollow noopener" target="_blank">#thread</a> <a href="https://mastodon.bsd.cafe/tags/sanitizer" class="mention hashtag" rel="nofollow noopener" target="_blank">#sanitizer</a> on a binary actually using LibreSSL and get sane output?What I now observe debugging <a href="https://mastodon.bsd.cafe/tags/swad" class="mention hashtag" rel="nofollow noopener" target="_blank">#swad</a>:- A version built with <a href="https://mastodon.bsd.cafe/tags/OpenSSL" class="mention hashtag" rel="nofollow noopener" target="_blank">#OpenSSL</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">#jmeter</a>, 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 😳

Felix Palmen :freebsd: :c64:More interesting progress trying to make <a href="https://mastodon.bsd.cafe/tags/swad" class="mention hashtag" rel="nofollow noopener" target="_blank">#swad</a> suitable for very busy sites!I realized that <a href="https://mastodon.bsd.cafe/tags/TLS" class="mention hashtag" rel="nofollow noopener" target="_blank">#TLS</a> (both with <a href="https://mastodon.bsd.cafe/tags/OpenSSL" class="mention hashtag" rel="nofollow noopener" target="_blank">#OpenSSL</a> and <a href="https://mastodon.bsd.cafe/tags/LibreSSL" class="mention hashtag" rel="nofollow noopener" target="_blank">#LibreSSL</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">#lockfree</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">#mutex</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. 😆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: <a href="https://dl.acm.org/doi/10.1145/248052.248106" rel="nofollow noopener" translate="no" target="_blank">https://dl.acm.org/doi/10.1145/248052.248106</a>

Felix Palmen :freebsd: :c64:This is going nice so far, I can now correctly sign my <a href="https://mastodon.bsd.cafe/tags/JWT" class="mention hashtag" rel="nofollow noopener" target="_blank">#JWT</a> (using <a href="https://mastodon.bsd.cafe/tags/LibreSSL" class="mention hashtag" rel="nofollow noopener" target="_blank">#LibreSSL</a> of course, so OpenSSL/LibreSSL will probably be an unconditional dependency for <a href="https://mastodon.bsd.cafe/tags/swad" class="mention hashtag" rel="nofollow noopener" target="_blank">#swad</a> in the next release)

Kevin Karhan :verified:<a href="https://mastodon.net2o.de/@forthy42" class="u-url mention" rel="nofollow noopener" target="_blank">@forthy42</a> doof nur dass es keine Alternativen abselts von <a href="https://infosec.space/tags/OpenSSL" class="mention hashtag" rel="nofollow noopener" target="_blank">#OpenSSL</a>, <a href="https://infosec.space/tags/LibreSSL" class="mention hashtag" rel="nofollow noopener" target="_blank">#LibreSSL</a> & <a href="https://infosec.space/tags/NSS" class="mention hashtag" rel="nofollow noopener" target="_blank">#NSS</a> gibt - und wer <a href="https://infosec.space/tags/PCIDSS" class="mention hashtag" rel="nofollow noopener" target="_blank">#PCIDSS</a> erfüllen muss, ist auf zertifizierte Binaries angewiesen!

Klaus Frank<a href="https://mastodon.social/@hanno" class="u-url mention" rel="nofollow noopener" target="_blank">@hanno</a> Speaking of <a href="https://chaos.social/tags/OpenSSL" class="mention hashtag" rel="nofollow noopener" target="_blank">#OpenSSL</a>, what's the state of <a href="https://chaos.social/tags/LibreSSL" class="mention hashtag" rel="nofollow noopener" target="_blank">#LibreSSL</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.

Neustradamus :xmpp: :linux:<a href="https://mastodon.social/tags/LibreSSL" class="mention hashtag" rel="nofollow noopener" target="_blank">#LibreSSL</a> 4.1.0 has been released (<a href="https://mastodon.social/tags/SSL" class="mention hashtag" rel="nofollow noopener" target="_blank">#SSL</a> / <a href="https://mastodon.social/tags/TLS" class="mention hashtag" rel="nofollow noopener" target="_blank">#TLS</a> / <a href="https://mastodon.social/tags/OpenSSL" class="mention hashtag" rel="nofollow noopener" target="_blank">#OpenSSL</a> / <a href="https://mastodon.social/tags/OpenBSD" class="mention hashtag" rel="nofollow noopener" target="_blank">#OpenBSD</a>) <a href="https://libressl.org/" rel="nofollow noopener" translate="no" target="_blank">https://libressl.org/</a>

ティージェーグレェI submitted a Pull Request to update MacPorts' LibreSSL to 4.1.0 here: <a href="https://github.com/macports/macports-ports/pull/28301" rel="nofollow noopener" target="_blank">https://github.com/macports/macports-ports/pull/28301</a> One of the GitHub Continuous Integration checks is queued, the other two are running. Hopefully they will go more smoothly than the got-portable0.111 and OpenSSH 10.0p2 PRs I submitted chocking on GitHub CI? Even if that proves to be true, it's up to someone else with commit access to merge it. <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=macports" class="mention hashtag" rel="nofollow noopener" target="_blank">#MacPorts</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=openssl" class="mention hashtag" rel="nofollow noopener" target="_blank">#OpenSSL</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=openbsd" class="mention hashtag" rel="nofollow noopener" target="_blank">#OpenBSD</a>

Peter N. M. HansteenLibreSSL 4.1.0 released <a href="https://www.undeadly.org/cgi?action=article;sid=20250430112153" rel="nofollow noopener" translate="no" target="_blank">https://www.undeadly.org/cgi?action=article;sid=20250430112153</a> <a href="https://mastodon.social/tags/openbsd" class="mention hashtag" rel="nofollow noopener" target="_blank">#openbsd</a> <a href="https://mastodon.social/tags/libressl" class="mention hashtag" rel="nofollow noopener" target="_blank">#libressl</a> <a href="https://mastodon.social/tags/ssl" class="mention hashtag" rel="nofollow noopener" target="_blank">#ssl</a> <a href="https://mastodon.social/tags/tls" class="mention hashtag" rel="nofollow noopener" target="_blank">#tls</a> <a href="https://mastodon.social/tags/security" class="mention hashtag" rel="nofollow noopener" target="_blank">#security</a> <a href="https://mastodon.social/tags/openssl" class="mention hashtag" rel="nofollow noopener" target="_blank">#openssl</a> <a href="https://mastodon.social/tags/networking" class="mention hashtag" rel="nofollow noopener" target="_blank">#networking</a> <a href="https://mastodon.social/tags/privacy" class="mention hashtag" rel="nofollow noopener" target="_blank">#privacy</a> <a href="https://mastodon.social/tags/crypto" class="mention hashtag" rel="nofollow noopener" target="_blank">#crypto</a> <a href="https://mastodon.social/tags/cryptography" class="mention hashtag" rel="nofollow noopener" target="_blank">#cryptography</a>

Neustradamus :xmpp: :linux:<a href="https://mastodon.social/tags/OpenBSD" class="mention hashtag" rel="nofollow noopener" target="_blank">#OpenBSD</a> 7.7 has been released (<a href="https://mastodon.social/tags/BSD" class="mention hashtag" rel="nofollow noopener" target="_blank">#BSD</a> / <a href="https://mastodon.social/tags/NetBSD" class="mention hashtag" rel="nofollow noopener" target="_blank">#NetBSD</a> / <a href="https://mastodon.social/tags/386BSD" class="mention hashtag" rel="nofollow noopener" target="_blank">#386BSD</a> / <a href="https://mastodon.social/tags/Unix" class="mention hashtag" rel="nofollow noopener" target="_blank">#Unix</a> / <a href="https://mastodon.social/tags/LibreSSL" class="mention hashtag" rel="nofollow noopener" target="_blank">#LibreSSL</a> / <a href="https://mastodon.social/tags/OpenSSH" class="mention hashtag" rel="nofollow noopener" target="_blank">#OpenSSH</a> / <a href="https://mastodon.social/tags/OpenBGPD" class="mention hashtag" rel="nofollow noopener" target="_blank">#OpenBGPD</a> / <a href="https://mastodon.social/tags/OpenSMTPD" class="mention hashtag" rel="nofollow noopener" target="_blank">#OpenSMTPD</a> / <a href="https://mastodon.social/tags/OpenNTPD" class="mention hashtag" rel="nofollow noopener" target="_blank">#OpenNTPD</a> / <a href="https://mastodon.social/tags/OpenIKED" class="mention hashtag" rel="nofollow noopener" target="_blank">#OpenIKED</a> / <a href="https://mastodon.social/tags/rpkiClient" class="mention hashtag" rel="nofollow noopener" target="_blank">#rpkiClient</a> / <a href="https://mastodon.social/tags/mandoc" class="mention hashtag" rel="nofollow noopener" target="_blank">#mandoc</a>) <a href="https://openbsd.org/" rel="nofollow noopener" translate="no" target="_blank">https://openbsd.org/</a>

Felix Palmen :freebsd: :c64:Released: <a href="https://mastodon.bsd.cafe/tags/swad" class="mention hashtag" rel="nofollow noopener" target="_blank">#swad</a> v0.1 🥳 Looking for a simple way to add <a href="https://mastodon.bsd.cafe/tags/authentication" class="mention hashtag" rel="nofollow noopener" target="_blank">#authentication</a> to your <a href="https://mastodon.bsd.cafe/tags/nginx" class="mention hashtag" rel="nofollow noopener" target="_blank">#nginx</a> reverse proxy? Then swad *could* be for you!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">#C</a> (+ <a href="https://mastodon.bsd.cafe/tags/POSIX" class="mention hashtag" rel="nofollow noopener" target="_blank">#POSIX</a>) with almost no external dependencies. <a href="https://mastodon.bsd.cafe/tags/TLS" class="mention hashtag" rel="nofollow noopener" target="_blank">#TLS</a> support requires <a href="https://mastodon.bsd.cafe/tags/OpenSSL" class="mention hashtag" rel="nofollow noopener" target="_blank">#OpenSSL</a> (or <a href="https://mastodon.bsd.cafe/tags/LibreSSL" class="mention hashtag" rel="nofollow noopener" target="_blank">#LibreSSL</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">#cookie</a> 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: <a href="https://mastodon.bsd.cafe/tags/PAM" class="mention hashtag" rel="nofollow noopener" target="_blank">#PAM</a>. But as pam already allows pretty flexible configuration, I already consider this pretty useful 🙈If you want to know more, read here: <a href="https://github.com/Zirias/swad" rel="nofollow noopener" translate="no" target="_blank">https://github.com/Zirias/swad</a>

jan Anja();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.<a href="https://github.com/urllib3/urllib3/issues/3020" rel="nofollow noopener" translate="no" target="_blank">https://github.com/urllib3/urllib3/issues/3020</a><a href="https://wetdry.world/tags/Python" class="mention hashtag" rel="nofollow noopener" target="_blank">#Python</a> <a href="https://wetdry.world/tags/Requests" class="mention hashtag" rel="nofollow noopener" target="_blank">#Requests</a> <a href="https://wetdry.world/tags/Urllib3" class="mention hashtag" rel="nofollow noopener" target="_blank">#Urllib3</a> <a href="https://wetdry.world/tags/OpenSSL" class="mention hashtag" rel="nofollow noopener" target="_blank">#OpenSSL</a> <a href="https://wetdry.world/tags/LibreSSL" class="mention hashtag" rel="nofollow noopener" target="_blank">#LibreSSL</a>

Peter N. M. HansteenRecent and not so recent changes in OpenBSD that make life better (and may turn up elsewhere too) <a href="https://nxdomain.no/~peter/blogposts/recent-and-not-so-recent_changes_in_openbsd_that_make_life_better.html" rel="nofollow noopener" translate="no" target="_blank">https://nxdomain.no/~peter/blogposts/recent-and-not-so-recent_changes_in_openbsd_that_make_life_better.html</a> from 2021 but has aged surprisingly well <a href="https://mastodon.social/tags/openbsd" class="mention hashtag" rel="nofollow noopener" target="_blank">#openbsd</a> <a href="https://mastodon.social/tags/freesoftware" class="mention hashtag" rel="nofollow noopener" target="_blank">#freesoftware</a> <a href="https://mastodon.social/tags/libresoftware" class="mention hashtag" rel="nofollow noopener" target="_blank">#libresoftware</a> <a href="https://mastodon.social/tags/libressl" class="mention hashtag" rel="nofollow noopener" target="_blank">#libressl</a> <a href="https://mastodon.social/tags/ssh" class="mention hashtag" rel="nofollow noopener" target="_blank">#ssh</a> <a href="https://mastodon.social/tags/pf" class="mention hashtag" rel="nofollow noopener" target="_blank">#pf</a> <a href="https://mastodon.social/tags/laptops" class="mention hashtag" rel="nofollow noopener" target="_blank">#laptops</a>

Bryan Steele :flan_beard:<a href="https://x.com/openbsd/status/1889330772399501381" rel="nofollow noopener" target="_blank">https://x.com/openbsd/status/1889330772399501381</a><blockquote>LibreSSL is not affected by the OpenSSL vulnerabilities announced today.</blockquote><a href="https://bsd.network/tags/openbsd" class="mention hashtag" rel="nofollow noopener" target="_blank">#openbsd</a> <a href="https://bsd.network/tags/libressl" class="mention hashtag" rel="nofollow noopener" target="_blank">#libressl</a> <a href="https://bsd.network/tags/openssl" class="mention hashtag" rel="nofollow noopener" target="_blank">#openssl</a>

Rafael SadowskiBig performance win in <a href="https://bsd.network/tags/LibreSSL" class="mention hashtag" rel="nofollow noopener" target="_blank">#LibreSSL</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&m=173900927421446&w=2" rel="nofollow noopener" target="_blank">https://marc.info/?l=openbsd-cvs&m=173900927421446&w=2</a>

ティージェーグレェI've been mulling over how to respond to this and trying my best to stick to the "what is kind, what is necessary, what is true" realms; rather than get lost in the weeds of a lot up exasperating personal experiences, since I am maybe a bit too close to the flame in some related subjects. Regarding who should maintain DSA code upstream once the OpenSSH devs decide they no longer want to? Ideally? At least in my humble opinion: no one! At least, no one who is part of the OpenSSH core group of developers. Some things deserve to stay in bitrot realms. Also see: DES. SSH = Secure Shell, not shell with known weak cryptographic constructs. Probably the same thing for SSLv3 in OpenSSL? Don't get me wrong, I have been deeply involved with software preservation efforts (e.g. I am cited in this 2009 Usenix presentation on restoration efforts that others and I helped out with as far as getting PDP11/20 asm [pre C] UNIX source in a manner that can be run: <a href="https://www.usenix.org/conference/usenix-09/restoration-early-unix-artifacts" rel="nofollow noopener" target="_blank">https://www.usenix.org/conference/usenix-09/restoration-early-unix-artifacts).</a> Having access to source code thankfully makes some of these kinds of things significantly easier than simply preserving binaries, so yolo-OpenSSL, yolo-OpenSSH, yolo-Python are all theoretically much easier projects than yolo-Raiden (an arcade game series, with 有限会社セイブ開発「yūgen kaisha seibu kaihatsu」levels of legendary ROM encryption techniques that took folks an awfully long time to break and even then, maybe not entirely? I haven't looked deeply into that stuff for a minute.) Very rarely I have been fortunate enough to have been paid to do that kind of work, so I am not exactly going to be able to advocate for that compensation in such realms as much as, that might be neat in theory? Not to mention, generally speaking; while I may do software preservation on occasion whether professionally or as a hobby, I usually get a lot more satisfaction with moving technology forward, rather than navel gazing at the distant past. Though I do understand why looking back can be necessary on occasion; I never want it to become the focus of my existence, at least not personally. However, since I have been paid in similar realms, I may as well mention some possibilities for those who may hope to have paid careers in such regards? For example: while I was IT Admin for iSEC Partners/NCC Group they had a "software escrow" division, which basically made a best effort to preserve a build environment, and then lock it in a vault. The reasoning I was told (paraphrasing): In the event some big corporation buys e.g. a little 4 person start up's technology and is worried that those 4 people will retire to the Bahamas, or die in a car crash or whatever and they don't want their investment in the acquired intellectual property to completely go up in smoke. Similarly, while I was staff at The MADE (Museum of Art and Digital Entertainment also see: themade.org), we would occasionally get requests about older technologies within our collection. On more than one occasion, I was tasked with re-creating prior art (using binaries/tools/etc. before a specific date) to help attorneys for Fortune 25 (then Alphabet Inc./Google) invalidate spurious patents, because we could demonstrate that such technologies existed before the patents. That kind of stuff is tedious, generally speaking, and extremely poorly paid (while The MADE for example, invoiced my time to Fortune 25 at $300/hour, I was lucky if I saw $15-$30/hour of that gross personally, making even Jeff Bezos' 50% cut of Twitch streamers' revenue look downright generous). There are other 501c3 non-profits (e.g. the Bloop Museum) which maybe do similar preservation work to The MADE? Honestly, one of the few real perks to working with The MADE is they had a Library of Congress granted DMCA exemption. Unfortunately, I have seen in the last year or two, efforts to undermine that sort of legislative sanctioned circumvention and I haven't worked for them since the pandemic caused them to close their doors to the public in 2020 either; so I don't know what the current legal climate is either. (The MADE did re-open at a new location in Oakland at least) AFAIK <a href="http://neohabitat.org/" rel="nofollow noopener" target="_blank">http://neohabitat.org/</a> (a preservation of the first MMO, Habitat on which The MADE collaborated) wasn't exactly generously funded and done more as a labor of love. Similar to my contributions to that PDP11/20 vintage UNIX stuff that got a Usenix presentation later, or maybe more recently (last Fall) when I created a MacPort for the first visual UNIX editor: <a href="https://ports.macports.org/port/em/details/" rel="nofollow noopener" target="_blank">https://ports.macports.org/port/em/details/</a> (based on Pierre Gaston's work to bring the preserved source code up to more contemporary UNIX variants. Lamentably, George Coulouris, the original author of em; also passed away in November of 2024, before I emailed him to let him know of my efforts.). I remember seeing some headlines about Sony looking to hire someone for software preservation several years ago, e.g. <a href="https://www.engadget.com/sony-playstation-game-preservation-team-143059442-143059184.html" rel="nofollow noopener" target="_blank">https://www.engadget.com/sony-playstation-game-preservation-team-143059442-143059184.html</a> Even though I have been in that field longer than most, I have no idea how I would even begin to get hired and paid a livable wage doing that sort of thing. Moreover, that's video games. When it comes to security critical code? OpenSSH and OpenSSL are AFAIK, mostly volunteer driven? There may be some nominal funding (at least in OpenSSH's instance, I think predominantly from the OpenBSD project and OpenBSD Foundation; I'm less sure about OpenSSL) but my guess is a lot of those resources are probably devoted to keeping servers and build infrastructure running and the financial costs incurred from such things? Particularly given how many downloads a lot of those projects require, even with myriad mirrors donating storage and bandwidth, it's a non-trivial amount of infrastructure to keep running presumably with some commensurate expenses? Having written as much, I was pretty impressed by someone's recent efforts on the LibreSSL mailing list mentioning porting LibreSSL to IRIX: <a href="https://marc.info/?l=libressl&m=173645350424685&w=2" rel="nofollow noopener" target="_blank">https://marc.info/?l=libressl&m=173645350424685&w=2</a> (the patch itself against LibreSSL 3.5.3 can be found here: <a href="https://pastebin.com/jaQwk729" rel="nofollow noopener" target="_blank">https://pastebin.com/jaQwk729).</a> I used IRIX systems extensively at nps.navy.mil in the early 1990s and to a lesser extent Cyberware (the first 3D scanners) yet I could never afford to own one myself [the VR Lab at the Naval Postgraduate School in Monterey had a Silicon Graphics ONYX Reality Engine² which I was given some "time" on and I was told cost $250,000, which was more than the mortgage cost on my parents' home for example]. As a bit of a tangent: I was even given a job offer by SGI in 2016 and was told they probably had some old Octanes lying around I would be welcome to see about using for preservation efforts. Unfortunately, though the interview went well enough for them to make me an offer, the offer was later rescinded and not long afterwards they were acquired by HP. ;( Moreover, probably the time I would have actually enjoyed working for SGI would have been in the early 1990s when I was using their systems extensively already; before they had devolved into a RHEL VAR, without getting into more boring personal details of my interactions with that company over the decades. So, similar to that PDP11/20 pre-C UNIX restoration work, my best hope would be maybe to run LibreSSL on IRIX via emulation (and I have no idea what the state of the art is for such things, if they even exist I haven't gone looking). Thankfully, emulation has really improved in the last few decades and makes a lot of preservation efforts easier and more economical to deal with as well. Similar efforts would be more the direction I would generally hope to see retrodev going? So, rather than keeping deprecated ciphers alive (aside from preservation and histrionics) IMHO, better to take more recent code (e.g. that LibreSSL 3.5.3 patch set for IRIX) and keep it running on older systems (when was the last time IRIX saw a release? 6.5, 1998?). Similarly, MacPorts seems to excel in similar realms with testing as far back as OS X Leopard on Intel and PPC and I've even seen mailing list traffic in the past couple of years of folks claiming MacPorts is still working like a charm on some older OS X Tiger systems?. Maybe that older hardware and those older OS builds are not as fast as contemporary systems, but I know I have appreciated running current versions of things like OpenSSH on older OSes and that's thanks largely to collaboration of a lot of individual (mostly volunteer I think?) contributors. So my guess is, whomever might maintain DSA for OpenSSH or SSLv3 for OpenSSL after the upstream projects have deprecated such things; it would probably be better for some kind of port/package management system? Maybe something like Nix or pkgsrc, with retro variant sensibilities? As contrasted with the usual /usr/ports which tends to try to keep -CURRENT with upstream even if the /usr/src may be older? Such things are going to vary a lot by OS and userland project no doubt. Again off on a tangent, a lot of this kind of stuff reminds me of Star Trek retrofits to particular USS Enterprise variants. ;) But real world military stuff sees retrofits and variants too, e.g. the F-14 was officially introduced in 1974 with the F-14B in 1987 and the F-14D in 1991. Code branches have similar parallels on occasion. CC: <a href="https://ieji.de/users/dboehmer" class="u-url mention" rel="nofollow noopener" target="_blank">@dboehmer@ieji.de</a> <a href="https://chaos.social/users/fluepke" class="u-url mention" rel="nofollow noopener" target="_blank">@fluepke@chaos.social</a> <a href="https://snac.bsd.cafe?t=ciphers" class="mention hashtag" rel="nofollow noopener" target="_blank">#ciphers</a> <a href="https://snac.bsd.cafe?t=preservation" class="mention hashtag" rel="nofollow noopener" target="_blank">#preservation</a> <a href="https://snac.bsd.cafe?t=yolo" class="mention hashtag" rel="nofollow noopener" target="_blank">#yolo</a> <a href="https://snac.bsd.cafe?t=deprecation" class="mention hashtag" rel="nofollow noopener" target="_blank">#deprecation</a> <a href="https://snac.bsd.cafe?t=irix" class="mention hashtag" rel="nofollow noopener" target="_blank">#IRIX</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=openssh" class="mention hashtag" rel="nofollow noopener" target="_blank">#OpenSSH</a> <a href="https://snac.bsd.cafe?t=openssl" class="mention hashtag" rel="nofollow noopener" target="_blank">#OpenSSL</a>

ティージェーグレェNice! <a href="https://chaos.social/users/neverpanic" class="u-url mention" rel="nofollow noopener" target="_blank">@neverpanic@chaos.social</a> 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? 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) <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>

R. L. Dane :Debian:Dear Python,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">#LibreSSL</a> (on <a href="https://alpha.polymaths.social/tags/openbsd" class="mention hashtag" rel="nofollow noopener" target="_blank">#OpenBSD</a>).The whole point is to not have the entire world using a single library for all encryption. That would not be enviable.<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>

Ólafur Jens Sigurðsson<a href="https://mastodon.social/@bagder" class="u-url mention" rel="nofollow noopener" target="_blank">@bagder</a> makes me wonder if <a href="https://c.im/tags/LibreSSL" class="mention hashtag" rel="nofollow noopener" target="_blank">#LibreSSL</a> is doing any better in that regard?

Recent searches

Search options

Administered by:

Server stats:

#libressl