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
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 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.
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.