Rafael Sadowski @sizeofvoid@bsd.network

OK, so #AI #bots have managed to bypass #Anubis - again. How much is the AI DDoS by now? So much that the Linux kernel can’t handle it anymore:

nf_conntrack: nf_conntrack: table full, dropping packet

And yes, this is seconds after rebooting the VM even.

This is insane.

OK, that’s it. Let’s shut down the internet, there is no point anymore. AI bots have destroyed it completely, there is no point in keeping iy anymore.

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

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