morgante
Joined 4 years ago
Karma
854
Submissions
243
Member since
Jul 27
Recent submissions
Comment · 1 year ago
We built on firecracker VMMs but today I'd just use a hosted provider like morph.so or e2b.dev.
Comment · 1 year ago
The exploit is there either way.
Comment · 1 year ago
You should treat running a code analyzer/builder/linter against a codebase as being no safer than running that codebase itself.
Comment · 1 year ago
A pretty straightforward solution is to have an isolated service that keeps the private key and hands back the temporary per-repo tokens for other libraries to use. Only this isolated service has access to the root key, and it should have fairly strict rate limiting for how often it gives other services temporary keys.
Comment · 1 year ago
Yikes, this is a pretty bad vulnerability. It's good that they fixed it, but damning that it was ever a problem in the first place.
Rule #1 of building any cloud platform analyzing user code is that you must run analyzers in isolated environments. Even beyond analysis tools frequently allowing direct code injection through plugins, linters/analyzers/compiler are complex software artifacts with large surface areas for bugs. You should ~never assume it's safe to run a tool against arbitrary repos in a shared environment.
I also ran a code analysis platform, where we ran our own analyzer[1] against customer repos. Even though we developed the analyzer ourself, and didn't include any access to environment variables or network requests, I still architected it so executions ran in a sandbox. It's the only safe way to analyze code.
Comment · 1 year ago
This is way too broad of a statement.
The smartest person and the dumbest person I've met professionally are both investors.
Comment · 1 year ago
They don’t elaborate on the logging details, but certainly must good systems don’t allow log tampering even for admins.
Comment · 1 year ago
All of those battles involve battlefield tactics, and in several of them the numerically inferior force won — exactly the opposite of "death stacks."
Comment · 1 year ago
Unfortunately nuance is dead. I too wish Musk had tried to empower USDS instead of immediately alienating many of the people best positioned to improve things.
Comment · 1 year ago
That's not true.
Look at USAID: they canceled everything, but there was a significant outcry about PEPFAR specifically. Now PEPFAR is back, and likely to stay.
Comment · 1 year ago
I'm not here to defend DOGE, but you're making the same mistake as the article of assuming the DOGE approach has no merit.
Deleting processes somewhat randomly, then listening for the pain, is a pretty well-known technique for understanding and cleaning up legacy systems. Of course, it should only be used on systems where (temporary) failures are tolerable.
There are parts of the government where that is true, and parts where it is dangerous. The problem on both sides is assuming the same techniques should be applied across the entire government, when some services are indeed life-and-death and others absolutely should be deleted.
Comment · 1 year ago
The efficiency comparison is interesting, since it starts relatively evenly but quickly dismisses the value of the DOGE approach. Everyone I know who worked at USDS has been talented and well-meaning, but I can't help but feel they've been hamstrung specifically by
1. Methodical improvements mostly work to improve processes as they are. They don't delete processes that shouldn't exist.
2. Agency "empowerment" often means working with a lot of incumbent teams that are simply not suited to digital work and sinks way too much time/energy into stakeholder management.
USDS has done good work, but could have done a lot more if they were actually empowered.
[1] https://www.wethebuilders.org/posts/a-tale-of-two-effiencies...