> The worse impact is that you have access to all the deploy keys, and on builds.sr.ht, there are deploy keys for sr.ht itself (probably not the case with other instances).
This is the most unexpected bit.
Circumstances made it so I got a new computer right around the time srht put out their anti-LLM policy. So I immediately started setting up a forgejo instance on my home network. With the latest waves of attacks on he AUR, I decided to keep that machine completely free from all AUR packages or helpers. So I also set up a package registry through the forgejo instance. With some work I have a workflow that takes a PKGBUILD and publishes an arch package that I can just `pacman - Syu` to install. Obviously I only put my own pkgbuilds and the few I have manually vetted there.
Even after manual vetting I wanted to lock things down as much as possible on the CI. So. I went with rootless podman, and some patching of arch's build infra just to get it to be able to run `pkgctl build`.
One of the main thing I looked out for was making sure no credentials were available anywhere during the jobs where the pkgbuilds (which can contain arbitrary commands) are being executed. I'm sure srht has to consider many more scenarios than I do. That will definitely make it harder to wall off credentials access. But it is still surprising that deploy keys are left laying around.
BTW this is not an attack on srht. I stopped actively using it because of their new policy. I still have a paid subscription that I do not plan to cancel anytime soon. I still have my public projects where I don't use LLMs there. I think opinionated maintainers and projects (Linus/linux, Poettering/systemd and Drew come to mind) are a net good for open source. Opinionated people make better software because they care imo. And those opinions don't have to be restricted to purely technical matters.
But anyway, it's a small team and there is a lot to cover, but they should get those leaking keys under control as much as possible.
I think you might have misunderstood. The source code of SourceHut itself is hosted on SourceHut, and it has a CI/CD setup that packages the microservices as alpine packages, signs and uploads them automatically to mirror.sr.ht, as files. This is no different than having a pypi-upload action (or similar) on GitHub.
The only material difference is that the deploy keys for *.sr.ht present (by design) on builds.sr.ht also have access to `doas apk upgrade -Ua` and to `doas rc-service *.sr.ht restart` on the production infra. Which is harmless by itself, but might result in Continuous Ownage if a rogue build happens to have access to the keys.
Yeah that's the same thing I do. Except the credentials to upload or to interact with the infra in any way are not available during the build job in the workflow. Forgejo reuses the same GitHub conventions so initially they were all available there too
It's a lot of different parts, the workflow itself is pretty straightforward. It is also all archlinux oriented because that's what I use everywhere. I'll try and clean it up over the weekend and make it available somehow. Where can I reach you once that's done?
> So if you happen to be able to make ␛]8;;https://example.com/"/...␇ appear in the job logs —4 which you can, either without even having an account, by sending a patch to a public mailing list with continuous integration turned on
The fact that this could be triggered so easily — just sending a malicious patch to a mailing list — is pretty insane.
I would prefer to do a super proper disclosure with coordinated release dates and everything. My first submitting to SourceHut security ML ended up making the vuln existence somewhat public before upstream ever knew.
Build logs are such a tricky attack surface; sanitizing arbitrary build output is practically impossible without breaking useful formatting. Always assume untrusted input.
Oh my God, it's OSC 8 again. Because copy-pasting an URI from the terminal window is so 2003, and goodness gracious, having to look at an actual URL instead of an arbitrarily inaccurate description of it? That's, like, 1993. When I wrote my variant of ansi2html, I aggressively stripped out every C0 and C1, and all of the possible APC/DCS/OSC/PM sequences.
Meanwhile, internal links between different parts of a man page still don't exist (unless you use GNU Info but seriously, I'd rather use lynx on a folder of HTML files instead).
They're also extremely useful for introducing CVEs into terminal emulators; I think I've seen about 5 of those on HN — including one OSC sequence that would cause the terminal emulator to just straight up automatically launch the web browser with whatever URLs were sent its way, no prompts no nothing.
I presume kgraves meant something along either lack of compensation being unfair to me, or me spoiling the market by being sort of fine with it, or both. It's a valid opinion to have.
I love sourcehut, and I can't really think anything to replace it. But here's my shot. It's a popular myth that independently from the project size, someone should always take the main stream product in the field than small projects because most of the people would use the main stream product and there's an higher chance that vulnerabilities get already exploited/recognized/fixed. Is that true or not? TL;DR: in the evaluation of such products (sourcehut but even self hosted stuff), should we also take account about the project history and the exposition to threats?
> The worse impact is that you have access to all the deploy keys, and on builds.sr.ht, there are deploy keys for sr.ht itself (probably not the case with other instances).
This is the most unexpected bit.
Circumstances made it so I got a new computer right around the time srht put out their anti-LLM policy. So I immediately started setting up a forgejo instance on my home network. With the latest waves of attacks on he AUR, I decided to keep that machine completely free from all AUR packages or helpers. So I also set up a package registry through the forgejo instance. With some work I have a workflow that takes a PKGBUILD and publishes an arch package that I can just `pacman - Syu` to install. Obviously I only put my own pkgbuilds and the few I have manually vetted there.
Even after manual vetting I wanted to lock things down as much as possible on the CI. So. I went with rootless podman, and some patching of arch's build infra just to get it to be able to run `pkgctl build`.
One of the main thing I looked out for was making sure no credentials were available anywhere during the jobs where the pkgbuilds (which can contain arbitrary commands) are being executed. I'm sure srht has to consider many more scenarios than I do. That will definitely make it harder to wall off credentials access. But it is still surprising that deploy keys are left laying around.
BTW this is not an attack on srht. I stopped actively using it because of their new policy. I still have a paid subscription that I do not plan to cancel anytime soon. I still have my public projects where I don't use LLMs there. I think opinionated maintainers and projects (Linus/linux, Poettering/systemd and Drew come to mind) are a net good for open source. Opinionated people make better software because they care imo. And those opinions don't have to be restricted to purely technical matters.
But anyway, it's a small team and there is a lot to cover, but they should get those leaking keys under control as much as possible.
I think you might have misunderstood. The source code of SourceHut itself is hosted on SourceHut, and it has a CI/CD setup that packages the microservices as alpine packages, signs and uploads them automatically to mirror.sr.ht, as files. This is no different than having a pypi-upload action (or similar) on GitHub.
The only material difference is that the deploy keys for *.sr.ht present (by design) on builds.sr.ht also have access to `doas apk upgrade -Ua` and to `doas rc-service *.sr.ht restart` on the production infra. Which is harmless by itself, but might result in Continuous Ownage if a rogue build happens to have access to the keys.
Yeah that's the same thing I do. Except the credentials to upload or to interact with the infra in any way are not available during the build job in the workflow. Forgejo reuses the same GitHub conventions so initially they were all available there too
Is your Forgejo+AUR workflow available? I'm looking to do the same (plus Vagrant and OCI images). Getting a headstart on hardening would be a boon.
It's a lot of different parts, the workflow itself is pretty straightforward. It is also all archlinux oriented because that's what I use everywhere. I'll try and clean it up over the weekend and make it available somehow. Where can I reach you once that's done?
Thanks, I appreciate it. Email to hn@zenoprax.com will reach me (reply will be from my real email).
> So if you happen to be able to make ␛]8;;https://example.com/"/...␇ appear in the job logs —4 which you can, either without even having an account, by sending a patch to a public mailing list with continuous integration turned on
The fact that this could be triggered so easily — just sending a malicious patch to a mailing list — is pretty insane.
Really commendable work fixing up the upstream python project. I don't think there's anything to be embarrassed about in the timeline.
I would prefer to do a super proper disclosure with coordinated release dates and everything. My first submitting to SourceHut security ML ended up making the vuln existence somewhat public before upstream ever knew.
Build logs are such a tricky attack surface; sanitizing arbitrary build output is practically impossible without breaking useful formatting. Always assume untrusted input.
Oh my God, it's OSC 8 again. Because copy-pasting an URI from the terminal window is so 2003, and goodness gracious, having to look at an actual URL instead of an arbitrarily inaccurate description of it? That's, like, 1993. When I wrote my variant of ansi2html, I aggressively stripped out every C0 and C1, and all of the possible APC/DCS/OSC/PM sequences.
Meanwhile, internal links between different parts of a man page still don't exist (unless you use GNU Info but seriously, I'd rather use lynx on a folder of HTML files instead).
OSC 8 hyperlinks are extremely useful for tables and other kinds of compact displays.
They're also extremely useful for introducing CVEs into terminal emulators; I think I've seen about 5 of those on HN — including one OSC sequence that would cause the terminal emulator to just straight up automatically launch the web browser with whatever URLs were sent its way, no prompts no nothing.
By "stripped out" I hope that means only accept colours and bold/underline and discard everything unrecognised :)
haven’t been properly rickrolled in years, wasn’t expecting that!
You're welcome!
Quality placement, no notes. I saw this comment before reading the article, still clicked it and felt got.
Congrats on the write up, seems extremely serious, I hope Sourcehut and Drew paid you well for this.
I hope they will one day. I said I'm fine with verbal credit if they don't have money, so I won't nag them unless I end up finding more.
A free-for-life "Professional hackers" package (https://sourcehut.org/pricing/) would be the minimum compensation in my eyes.
> I hope they will one day. I said I'm fine with verbal credit if they don't have money,
This is quite disappointing, but I guess it is your choice.
What's disappointing? I feel like I missed something.
I presume kgraves meant something along either lack of compensation being unfair to me, or me spoiling the market by being sort of fine with it, or both. It's a valid opinion to have.
nitpick: typo "Vulnerabile" :)
Fixed! (You can send me patches for https://git.sr.ht/~arusekk/arusekk.srht.site too)
I love sourcehut, and I can't really think anything to replace it. But here's my shot. It's a popular myth that independently from the project size, someone should always take the main stream product in the field than small projects because most of the people would use the main stream product and there's an higher chance that vulnerabilities get already exploited/recognized/fixed. Is that true or not? TL;DR: in the evaluation of such products (sourcehut but even self hosted stuff), should we also take account about the project history and the exposition to threats?
HN hug of death, strikes again.
That might have been DNS, the website itself is on sourcehut pages. Should be fine now for a while.