But could also be any of the recent supply chain attacks hitting a dev too i guess
How they handle the communication on the incident is crucially as important as remediating the original cause.
Just the fact that they are doing this means I will probably never use this service or recommend this service to anyone else.
The founder of the company has already emailed you with details and their support team is around for you to ask any follow-up questions. Also the bug/exploit has been fully fixed
At this point are you saying you would actually be upset and leave because the incident on their status page has been marked as resolved?
HN is very cesspool-ly indeed
That's what you are doing, congratulations
- did they just take the affected API offline?
- or did they just disable the account of the attacker?
- or is the exploit actually being fixed?
Environment variables are sensible data, and marking a security incident as resolved with that little detail is quite a take. Even changelog entries for harmless bug fixes are more detailed.
Their customers now have an incident that will be resolved once their secrets are rotated. Maybe they also need to do previous intrusion forensics… In any case, not triggers problem anymore.
Eternity is a very, very long time. Longer even than 80 years (arguably the total age of the whole "programmable electronic computing and data storage machines" industry), you know?
So I don't think that having an open issue in a bug tracker forever is even possible; not that it would even serve as a remainder — I assure you, most long-existing firms have "ignore open issues older than X years" filter enabled by default in their Jiras or whatever people use nowadays, those are only ever looked at once year by the upper management when they're out of ideas.
Thanks for that anecdote
There is a difference between using AI to find bugs in written software than using AI to write bug free software, completely different set of skills and outcomes. Most of the high profile stuff you see is AI being driven by people who would have solved the same problem just in slower time going through the code. AI is as good as the operator.
they had a priviledge escalation vulnerability that requires the attacker to already be a part of the tailnet, and more specifically allows a user-to-root escalation devices the attacker can tailscale ssh to.
> Not trying to play down the vuln (its important), but its not a free-for-all RCE that some ppl are acting like it is. [1]
eMudhra/TLS certificates have nothing to do with this (?).
Someone will inevitably spin up a large swath of agents running an abliterated pareto curve model and point them at the internet.
Not to mention your bespoke tool is likely way less hardened than the existing player in the space.
And keep private and public personal hosted services in different contexts.
Im now thinking about just running tart VM's on my mac to do my regular stuff from.
Despite no using full VM's I using Orbstack Isolated machines to some level of restrictions https://docs.orbstack.dev/machines/isolated for coding.
Go has lots of mature in-process queue systems, yet River exists, because in lots of situation it makes perfect sense to have your job queue in its own process
It's missing lots of features like sleeping on waits, warm starts etc.
I was able to patch before it was exploited but that definitely made me question the service.
Unfortunately for infra startups, I think we're going to see a convergence back to hyperscalers as a result of incidents like this and railway.
There's no amount of "nicer to use" that can replace security, at least certainly when selling to enterprises
Also, a trick i've started doing is encrypting my env vars, then hard-code the decryption key in the code
Just becuase a company has more money doesn’t mean they direct that money well, and even money directed well at the wrong people will result in failures.
One person's machine being compromised does not bring the whole org down.
500 Internal Server Error