Top
Best
New

Posted by passenger 5 hours ago

Security Disclosure(blog.railway.com)
344 points | 186 commentspage 4
barelysapient 3 hours ago|
Ugh. Love Railway.
sergiotapia 4 hours ago||
Actually I will move my projects away from Railway. With AI what it is today, no reason to shy away from hosting on actual VPS.

What is the best VPS to use today? Is it still hetzner or ovh?

lijok 5 hours ago||
Damn I guess all those l33t hiring practices were for nothing
rvz 5 hours ago|
Of course, it was a giant scam that tested for nothing and optimized for how to pass a test.

Let's see if companies are ready to hire more people who know what they are doing, against a super-intelligent swarm of millions of agents with cyber capabilities.

Keloran 5 hours ago||
Well this is certainly interesting, I wonder how their secrets were being stored, I assumed they were stored in vault and then injected with a sidecar, but I guess not
esseph 5 hours ago||
Fuck, I thought this was about trains
goforbg 4 hours ago||
the worst service I've signed up for has to be railway. What a terrible product.
dayyan 4 hours ago||
[flagged]
jon128 3 hours ago||
[dead]
torben-friis 4 hours ago||
>We believe this is part of a series of attacks recently targeting platform companies with the aim of compromising AI inference providers.

Is that an accusation? As in, major AI players taking out competitors ?

paulgb 48 minutes ago|
I don’t think that’s what’s implied here. Possibly they are trying to get API tokens of providers to distill their own models.
visch 3 hours ago|
This is exactly why we should own our deployment stacks. Going to push up the launch here as pdt is a railway alternative thttps://github.com/autoidm/pdt for scheduled jobs

AI makes this so much easier to do now, we should all own our own code, and deployment infrastructure (use a cloud instead of someone wrapping aws for you)

skwirl 3 hours ago|
Do you own argcomplete, backoff, certifi, cffi, charset-normalizer, cryptography, google-auth, google-auth-oauthlib, idna, markdown-it-py, mdurl, msal, oauthlib, pyasn1, pyasn1-modules, pycparser, pygments, pyjwt, python-dotenv, pyyaml, requests, requests-oauthlib, rich, rich-argparse, shellingham, and urllib3?
visch 2 hours ago||
No, and this isn't about a supply chain attack on Python libs. This is about running your service(s) on a service that runs in front of a cloud provider. My argument is simply that it's needless extra risk

You do have an argument to be made about vendoring our dependencies, or removing them in general. Not a bad idea