I submitted a Pull Request to update MacPorts' LibreSSL to 4.1.0 here:

https://github.com/macports/macports-ports/pull/28301

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.

#LibreSSL #MacPorts #TLS #OpenSSL #macOS #OpenBSD

@dexter reblog status of @zirias@bsd.cafe:
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

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: https://www.usenix.org/conference/usenix-09/restoration-early-unix-artifacts).

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 http://neohabitat.org/ (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: https://ports.macports.org/port/em/details/ (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. https://www.engadget.com/sony-playstation-game-preservation-team-143059442-143059184.html

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: https://marc.info/?l=libressl&m=173645350424685&w=2 (the patch itself against LibreSSL 3.5.3 can be found here: https://pastebin.com/jaQwk729).

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: @dboehmer@ieji.de @fluepke@chaos.social

#ciphers #preservation #yolo #deprecation #IRIX #LibreSSL #OpenSSH #OpenSSL

Nice! @neverpanic@chaos.social just merged a Pull Request (specifically https://github.com/macports/macports-ports/pull/26827) 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)

#MacPorts #LibreSSL #TLS #macOS #OSX #OpenSSL #OpenSource

Обновился #OpenSSL до 3.4.0 и опять без полноценной нормальной поддержки #QUIC, т.е. непригодный для #HTTP/3 на серверной стороне. И, соответственно, ещё не ясно на сколько хорошо сделана клиентская часть :)
Аж вспомнились времена, когда желая получить #curl поддерживающий нормально работу #HTTP/3 приходилось собирать его из исходников с аналогами/форками #OpenSSL.

#HTTP/3 работает не через tcp-соединения, а использует в качестве транспорта протокол QUIC (Quick UDP Internet Connections), т.е. передаёт данные поверх udp без использования абстракций и сущностей tcp. Вот картинка про современный #HTTP

Сам по себе #QUIC не умеет передавать данные в открытом виде, а может только через #TLS v1.3, т.е. в обязательном порядке только зашифрованные. Тем самым в QUIC используется встроенный вариант TLS 1.3 крайне близкий/схожий с #DTLS, поскольку работа протокола идёт на уровне обмена udp-пакетами, а не tcp-соединений.

#curl может использовать разные альтернативы OpenSSL, т.к. изначально спроектирован таким образом, что не завязан именно на OpenSSL:

• Есть официальная документация что и как с бэкендами вообще.
• Рядом, примерно там же имеется сравнение разных криптографических бэкендов.

Что предлагают по HTTP/3 авторы curl?
Вот зелёным выделена комбинация библиотек, которую полагают наиболее стабильным и полноценным вариантом
Вся загвоздка в том, что #OpenSSL пытается содержать в себе реализацию #QUIC, а не использует реализацию в виде какой-то библиотеки.

Что получается в целом?
Протокол #HTTP/3 реализуется через библиотеку #nghttp3.
Необходимая реализация #QUIC через #ngtcp2.
А для TLS используется #GnuTLS или же #wolfSSL или что-то ещё:

The OpenSSL forks #LibreSSL, #BoringSSL, #AWS-LC and #quictls support the QUIC API that #curl works with using #ngtcp2.

Вот из документация примеры и детали по сборке этих составляющих. Если выбрана #GnuTLS и в системе версия далёкая от свежих, то сама она довольно быстро собирается из исходников.

В целом, вообще, про варианты добавления поддержки #HTTP/3 очень достойно расписано здесь. И есть перевод этой публикации на русском языке.

#https #http #openssl #softwaredevelopment #lang_ru @Russia

I submitted a Pull Request to update MacPorts' LibreSSL to 4.0.0 here: https://github.com/macports/macports-ports/pull/26165

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