@tobhe Neither did I, and then Robert came around the corner

Kudos to Robert Nagy (robert@). Without much fuss, he committed OpenWV and enabled Widevine support in Chromium. Now we can all enjoy Netflix, Disney+, and other DRM content on #OpenBSD.

https://marc.info/?l=openbsd-ports-cvs&m=176850784406383&w=2
https://marc.info/?l=openbsd-ports-cvs&m=176850824206836&w=2

I hope you all had a good start to the new year. For my part, I am looking forward to 2026! Every year can be the best year ever. It's up to you!

2025 was a year in which I wrote more than I had done in a long time. I am considering continuing to do so. Perhaps in a slightly different way. I would like to use this blog more to summaries what I am learning during a month or events.

The travel list has also grown this year and welcomed a new guest with Japan.

https://rsadowski.de/posts/

Escaping Containment: A Security Analysis of FreeBSD Jails has been released on media.ccc.de #39c3 #Security #Fuse #39c3eng #39c3deu https://media.ccc.de/v/39c3-escaping-containment-a-security-analysis-of-freebsd-jails https://events.ccc.de/congress/2025/hub/event/detail/escaping-containment-a-security-analysis-of-freebsd-jails

Golden opportunity to become a reverse centaur! You only need to audit/review 5,600 lines of c++ code ported to rust per hour!

http://rkta.de/ssh-tmux-reattach.html

New #blog post clearly inspired by @sizeofvoid 's:
https://www.rsadowski.de/posts/2025/ssh-tmux-reattach/

#ssh #tmux

Driving home for Christmas...

@ezaquarii When I have time again to make countless forks, clones, patches, pushes, PRs, yes ;)

@Quillaja No, I built it from a ports proposal. But it should be available in the next package build.

I'm looking for an Apple Mac mini (M2 Pro) to build and test arm64 ports. https://www.openbsd.org/want.html

OpenSSH runs a large number of tests via Github Runners, both Github supplied ones on a public repo, and on selfhosted runners on a private repo. The latter covers a bunch of platforms Github doesn't support, and is private not because we don't want it accessible (in fact we would prefer it be public) but because as far as we can tell, making it public would represent a significant security risk.

Github have announced that they will begin charging per-minute fees for Github Actions self-hosted runners starting next year. These fees apply only to runners on private repos, but "actions will remain free in public repositories."[0] This is going to be a significant problem for us.

Github's own documentation points out allowing selfhosted runners on public repositories is unsafe, because it's a potential remote code execution vector via running arbitrary workflows in modified pull requests:

"As a result, self-hosted runners should almost never be used for public repositories on GitHub, because any user can open pull requests against the repository and compromise the environment."[2]

There are some controls[1], but the documentation on them doesn't exactly instill confidence (emphasis on the weasel words added):

"Anyone can fork a public repository, and then submit a pull request that proposes changes to the repository's GitHub Actions workflows. [...] To *help* prevent this, workflows on pull requests to public repositories from *some* outside contributors will not run automatically, and *might* need to be approved first. Depending on the "Approval for running fork pull request workflows from contributors" setting, workflows on pull requests to public repositories will not run automatically and *may* need approval if: The pull request is created by a user that requires approvals based on the selected policy.[or] The pull request event is triggered by a user that requires approvals based on the selected policy."

All of this uncertainty could be addressed by completely disabling pull requests on a repo, but while that has been requested many many times over the course of a decade([3] [4]), this is still not possible.

It *is* possble to *temporarily* disable pull requests on a repository via Interaction Limits[5], but using this as a security control that (silently?) fails open after some amount of time is problematic to say the least. The required functionality is almost there, it just needs a "forever" option.

So, in summary: self-hosted runners remain free as long as you run them on public repos, which you shouldn't because it's unsafe, unless you also disable pull requests, which you probably can't.

[0] https://resources.github.com/actions/2026-pricing-changes-for-github-actions/
[1] https://docs.github.com/en/repositories/managing-your-repositorys-settings-and-features/enabling-features-for-your-repository/managing-github-actions-settings-for-a-repository#controlling-changes-from-forks-to-workflows-in-public-repositories
[2] https://docs.github.com/en/actions/reference/security/secure-use
[3] https://github.com/orgs/community/discussions/8907
[4] https://github.com/dear-github/dear-github/issues/84
[5] https://docs.github.com/en/communities/moderating-comments-and-conversations/limiting-interactions-in-your-repository

Native Signal Messenger support via net/#flare-messenger on #OpenBSD

OpenBSD ports are in an incredible rush!

- devel/gdb is currently getting a lot of improvements by kurt@

- The default GCC compiler has been switched from 8 to 15! This means modern C++ under sparc64!

- Qt 6.10.1 is here (still a bit glitchy but soon to be stable as packages)

- KDE Plasma 6.5

- Python 3.13.11 and thus 3.13 for OpenBSD 7.9

- Go 1.25.5

Petition for German residents regarding Open Source Contribution:

https://www.openpetition.de/petition/online/anerkennung-von-open-source-arbeit-als-ehrenamt-in-deutschland#petition-main

I would be delighted if many people would sign. Thank you!

#OpenBSD #KDE #Qt update: Plasma 6.5.3, Qt 6.10.1, Qt 5.15.18 + KDE patches, Newest QtPy stack. It couldn't be any more up to date. That was a lot of work! Now it's time to get it into the cvs tree so that everyone can use it soon.

3 major outages in a few weeks: AWS, Azure, now Cloudflare. Is there a correlation between AI age and these outages?

The AI age paradox: The "smarter" our systems get, the dumber the errors that kill them?

Marathonas - Athens Marathon - The Authentic

I forced some of my boxes to only use SSH post-quantum algorithms like mlkem768x25519-sha256. I have #OpenSUSE Tumbleweed on one of my desktops. It turns out that these are not enabled by default: https://bugzilla.suse.com/show_bug.cgi?id=1253025

First, you have to make complicated adjustments to two files:

/etc/crypto-policies/config
/etc/crypto-policies/policies/modules/SSH-QUANTUM.pmod

What kind of nonsense is this? #Unsecure by default?

https://news.opensuse.org/2025/05/02/tw-monthly-update-april/

This how "try-and-error qtwebengine-6.10.0 porting" looks like: