What's cooking on SourceHut? Q2 2026
Hello everyone! It’s time for another quarterly update, keeping you up to date<br>on what we’re cooking up here at SourceHut.
Drew’s update
This past quarter I found myself mostly focused on “invisible” labor for<br>SourceHut, which will make for a boring update from me this time. Most of my<br>time was spent preparing a grant proposal, jointly with some other open source<br>forges and related partners, to apply for funding from the EU. We’ll learn how<br>that went sometime next quarter!
Otherwise I’ve been focused on greasing the wheels and keeping the lights on –<br>doing code reviews, fixing little bugs here and there, handling user support,<br>mitigating rolling DDoS attacks (Conrad will elaborate on these in a moment),<br>dealing with the finances (it’s tax season), and enjoying some rest after<br>dealing with all of the above.
In the coming quarter, I plan to write our annual financial report, and to<br>invest more time in user-visible improvements. There’s a lot of work going into<br>our GraphQL APIs now (led by Simon Martin!) which I want to build on. With this<br>momentum I also plan to look into anonymous API access and more standardized and<br>uniform GraphQL API designs, such as support for the connections specification<br>for resource enumeration.
We’ll leverage these API improvements to facilitate some long-awaited features,<br>such as linking resource pages (e.g. git repos) back to the projects they belong<br>to on the project hub. I also plan on doing some more work on the billing<br>system, to finalize the migration to the EU, so if this works out all customers<br>will be moved into the EU billing system soon enough.
Conrad’s update
While I did get good deal done this quarter, some of that work was certainly of<br>the kind I wish I wouldn’t have to do in the first place. Let’s start with the<br>elephant in the room: the DDoS. We still remain cautious about sharing too many<br>details, but we wanted to at least offer a little glimpse into what we were<br>facing. The below graph was provided by our network provider. For scale, note<br>that the baseline traffic you can make out is not just ours - it’s us plus<br>other customers. The visible spikes, however, were unfortunately directed at us<br>alone…
The graph is from some time ago. A few more waves came in after that. We are<br>still on alert and of course discussing what if any mitigations we can put in<br>place for such events in the future.
There is a small silver lining to this. The DDoS came in several waves of<br>different traffic patterns, but it was mostly aimed at network resource<br>exhaustion. This “helped” us identify several places where internal network<br>traffic (such as inter-service requests) was still routed over public (that is,<br>saturated) interfaces. Those were all fixed and we were happy to see that<br>afterwards those few requests that made it to our servers could successfully be<br>handled.
Hot on the heels of the DDoS we were targeted by another huge wave of spam<br>sign-ups. These are accounts that get created solely for link farming. They<br>basically get an advertisement with one or more links in their bio and never<br>get used again. This time around, there seems to have been a serious campaign<br>going on, creating over 300 accounts in a single month. We’ve seen such<br>campaigns before, but we were mostly able to stall them by blocking the email<br>domains they were using, which often seemed to be from obscure, hijacked relays<br>or such. Unfortunately, by now, the main offender for fake accounts has become:<br>Gmail… sad trombone
So we had to resort to other means, and I added a keyword capability to our<br>abuse detection system. All profile updates are now checked against certain<br>keywords, and if there are a certain number of matching keywords the account is<br>suspended right away. We will be very careful with the keywords we add to<br>this to avoid false positives. The kind of crap we are dealing with is<br>fortunately pretty easy to detect with 100% accuracy.
Let’s talk about more interesting stuff. My favorite this quarter is of course<br>that I managed just right on time to finish git.sr.ht deploy keys! In the<br>“Access” tab of your repository settings, you can now add SSH keys which will<br>be able to access only this very repository, either read-write or read-only.<br>This is intended for keys used for example in CI or similar automation.
This work was preceded by a clean-up of the meta.sr.ht SSH key handling, with<br>the user-visible side effect that finally SHA256 fingerprints are used<br>everywhere as opposed to the legacy MD5 fingerprints.
Besides the few fixes here and there I also floated a first patch to replace<br>the builds.sr.ht shell (currently Python) with a Go implementation. It might<br>need a few fix-ups, but it already went through an RFC phase, so I think it’s<br>fair to mention this now and call it a day.
Everyone else
SourceHut is 100% free and open source...