staticassertion

6 ms·

1.
by staticassertion 4mo ago
Docker is a lot more than just an unprivileged user. In particular, it comes with a seccomp filter. A lot of LPEs are blocked by that filter. Docker is actually a quite decent security boundary - in this case the attackers did not attempt t
2.
by staticassertion 4mo ago
The solution is to do exactly what you suggest - separate access. In CI this is a matter of having your "build/test" jobs happen separately from your "deploy/publish" jobs. The trickier part is dev environments
3.
by staticassertion 4mo ago
No. NPM's not particularly bad at all tbh.
4.
by staticassertion 4mo ago
Most of them definitely let you do that.
5.
by staticassertion 4mo ago
That seems like the opposite. Why would someone with high market value stay in one place? 2 years is basically optimal - you vest 50%, maybe collect a promotion, do some good work and learn a lot, and then get to move on for another solid b
6.
by staticassertion 4mo ago
> The harder question is what the architecture around the vulnerability should look like. The principle is to make exploitation harder for an attacker even when a bug exists, so that the gap between when a vulnerability is disclosed and
7.
by staticassertion 4mo ago
I was rejecting your definition of the hard problem as it contains an assertion that a physicalist wouldn't accept. Yes, reduction would be one very viable strategy. It doesn't require precisely defining the phenomenon in order fo
8.
by staticassertion 4mo ago
> The hard problem identifies the in principle difficulty in explaining phenomenal consciousness, something not definable in terms of structure and function Great, I'm a physicalist so uhhhh I reject this lol. I think you can define
9.
by staticassertion 4mo ago
That's like saying that "water" is a philosophical invention and so if you accept that water is a thing then you've put it into a special category. You can derive consciousness as a somewhat obvious conclusion of empiric
10.
by staticassertion 4mo ago
That's true and probably a kinda critical distinction here. Facebook is sort of making the bet that they can not only treat the world like shit but their direct employees too.
11.
by staticassertion 4mo ago
You could have said this every year for so many years about so many companies. If people will work for Palantir, they'll work for Facebook. Facebook could be a lot worse and I think a lot of their employees would stick around. I gues
12.
by staticassertion 4mo ago
> The no-AI policy of the Zig compiler project is for the compiler, other projects can do whatever they want. Well, presumably they want to contribute to the compiler. I know that you did not like those contributions, and that view seems
13.
by staticassertion 4mo ago
Yes. The policy is pretty clear on what the rules are for LLM generated code. You need a reviewer to agree to review LLM generated code, you need to read the code yourself, etc.
14.
by staticassertion 4mo ago
I think that the only significant caveat here is the need for reviewers to opt in, otherwise it's effectively "you can do it if you are open about it and are responsible for the output". The only notable ask here that's
15.
by staticassertion 4mo ago
I guess that's the problem with the term. It should likely be left entirely out of a document like this since it's just confusing.
16.
by staticassertion 4mo ago
I'm not making a claim about this bug, I'm saying that oracles and leaks are common and that nginx seems like a good target for them.
17.
by staticassertion 4mo ago
What are you even talking about lol the policy doesn't imply that at all. That's in the "allowed with caveats" section. It's just saying to not open bug reports without first reading them yourself or your bug may be
18.
by staticassertion 4mo ago
Information leaks are not uncommon at all. nginx seems like a good target for them as well (fork + exec == no re-randomize, so you have the ability to reexec your exploit a lot of times to improve stability). edit: Seems that there's
19.
by staticassertion 4mo ago
> even when the rust-lang/rust repository itself largely forbids vibe coding. This policy does not seem to forbid vibe coding?
20.
by staticassertion 4mo ago
They're just giving examples of what you can do and explicitly saying so. Saying "you couldn't stop me" is completely missing the point. This is not very different from the Linux kernel's policy so it's an odd
21.
by staticassertion 4mo ago
This policy is straightforward and shouldn't be particularly controversial (I'm sure it will be bikeshedded to death though). It basically bans the obvious stuff ("don't just drop LLM generated comments onto PRs") a
22.
by staticassertion 4mo ago
You should sandbox where you run the code. The thing is, it's very hard for me to know how to sandbox an install script, but it's actually quite easy (and my responsibility as the app dev) to know how to sandbox my tests/ app
23.
by staticassertion 4mo ago
I assume that increasing the taxes would just lead to higher rents, right?
24.
by staticassertion 4mo ago
Yes, that is the threat I'm most worried about as well. But look at your description of it - a repo admin has to be compromised. Not just "random engineer". Although, in this case, the attacker leveraged a cache poisoning a
25.
by staticassertion 4mo ago
Because it does. The attack has to involve the CI pipeline rather than the dev environment, there's no token to revoke after (if you evict the attacker you're done, the OIDC credentials expire), it's easier to monitor for ext
26.
by staticassertion 4mo ago
I still think that Trusted Publishing is a significant win but I do like the idea of requiring a second factor to mark a release as truly published. It would make these CI worms very hard to pull off.
27.
by staticassertion 4mo ago
That's what they're doing.
28.
by staticassertion 4mo ago
Yes, but you really have to go out of your way to segfault/ run afoul of memory safety issues, which are a pain in the ass to debug.
29.
by staticassertion 4mo ago
You can use arenas in Rust, it's just not as trivial to swap allocators generally. But there are plenty of crates for it.
30.
by staticassertion 4mo ago
I don't see any reason why the approach wouldn't hold just fine, if not better, as the codebase scaled. Indeed this appears to be exactly what the author has done, they mention that they made heavy use of crates.

More ›