staticassertion

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 to subvert docker by attacking the kernel attack surface, they attacked a weak configuration via the docker socket being mounted.

The reason you don't use a "grown up VM" is because it's significantly more difficult. Which VM? Firecracker requires KVM and a guest operating system - so how are you getting things in and out in a way that doesn't violate security? That's real work.

gVisor is great and my recommendation, certainly, but the difference between "nothing" and "docker" is actually pretty huge imo.

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, but ideally you take a similar approach. The place that devs do `npm install` should be isolated from, say, your browser / ssh keys etc.

Package manager support would be an amazing win here since you'd have an easier time managing the isolation but you can do this today.

No. NPM's not particularly bad at all tbh.

Most of them definitely let you do that.

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 bump/ promotion and a new set of stocks.

I expect the people with low market value to be the ones sticking around labs for long periods of time, they don't have the option to move and they aren't getting poached.

> 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 when it is patched matters less. That means defenses that sit in front of the application and block the bug from being reached. It means designing the application so that a flaw in one part of the code cannot give an attacker access to other parts. It means being able to roll out a fix to every place the code is running at the same moment, rather than waiting on individual teams to deploy it.

So nothing new then.

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 for me to just say that it reduces based on the fact that reduction has been a successful approach for everything else in cognition.

> There is an in principle barrier to a transparent structural description of phenomenal consciousness.

Yeah this is what I reject. Why do you say that this is in principle a barrier? You're discussing it as an explanatory gap, not in principle.

> 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 cognitive capabilities and phenomenal experience by reducing to structure and function. You're right that it's simple though.

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 empirical study of behaviors, we have multiple fields of study that lay out cognitive function and criteria.

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.

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 guess a response at the industry level would be not hiring ex-FB people etc, treating it as a red flag.

> 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 entirely valid, but obviously "no AI" rules out their development model (by design, and you likely think that's good, and maybe it is!).

Not intending to defend the bun move, but obviously a project using Zig and also using AI might feel motivated to avoid Zig since they're ruled out as contributors.

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.

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 different from other policies is "if it's an LLM, tell reviewers beforehand".

TBH I think that makes no sense ("I have an LLM written PR ready, can I open it?") but yeah the policy is also in draft and has actually already changed since my first comment.

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.

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.

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 closed. No one is saying "by policy we will have to add the bug back in" jesus christ

The policy is insanely straightforward, idk how you can be misinterpreting it this badly. It's just "Disclose that you use a model, you are on the hook for reviewing model output as a human" and then some clear cut examples.

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 already good work in this area, I kinda forgot about brop gosh I'm old https://www.scs.stanford.edu/brop/

I suppose to keep the password analogy together, people reuse passwords all the time, timing attacks exist, etc?

> even when the rust-lang/rust repository itself largely forbids vibe coding.

This policy does not seem to forbid vibe coding?

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 comparison. It's actually almost identical in practical terms.

edit: lol proof that this doc needs to be stupidly explicit is in the pudding with the HN comments going out of their way to radically misread it

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") and allows the important stuff like LLMs writing code so long as you disclose.

edit: Wow people did not read the policy. It's literally just "if you use an LLM you are responsible for it, we will reject low quality PRs, please disclose that you have used an LLM". This is bog standard.

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/ application.

I assume that increasing the taxes would just lead to higher rents, right?

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 attack to move into the privileged workflow and I suspect this sort of thing will be commonplace.

I'm in agreement that a second factor would be ideal, to be clear. I think it's a good idea, something like "package is released with Trusted Publishing, then 'marked' via a 2FA attestation". But in theory that 2FA is supposed to be necessary anyways since you can require a 2FA on Github and then require approvals on PRs - hence the cache poisoning being required.

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 externally, you can build things like branch protections in and isolate things like "run tests" from "publish", etc. Trusted Publishing is not itself a solution to all supply chain issues but it is a massive improvement.

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.

That's what they're doing.

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.

You can use arenas in Rust, it's just not as trivial to swap allocators generally. But there are plenty of crates for it.

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.