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?

For this particular bug, for that to apply, you need some sort of oracle which tells that you are actually in the same child process that skips re-randomization before you can reduce the entropy. Based on this post, I cannot see that there is stable oracle to tell that?

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.

It does in the narrower sense of vibe coding (as opposed to more general agentic coding, which is also called vibe coding from time to time...).

> Solicited, non-critical, high-quality, well-tested, and well-reviewed code changes that are originally authored by an LLM are allowed, with disclosure.

Vibe coding (in its original meaning) would have hard time arguing it's of high quality.

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 read it as a hypothetical

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.

So...big caveat that this is still under review, so what we're talking about is a moving target, but based on what I can see, it seems considerably more nuanced than that. They basically ban LLM-authored code, with a careful carve-out to run an experiment to try to get only high-quality LLM PRs:

> It's fine to use LLMs to answer questions, analyze, distill, refine, check, suggest, review. But not to create.

> We carve out a space for "experimentation" to inform future revisions to this policy.

Importantly, the LLM contributions must be solicited, i.e., the people responsible for reviewing the final implementation have to opt in explicitly beforehand.

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.

"allows the important stuff like LLMs writing code so long as you disclose."

Are you sure? It says:

"It's fine to use LLMs to answer questions, analyze, distill, refine, check, suggest, review. But not to *create*."

It's a pretty strict ban, with an exception.

That exception is experimental and somewhat limited; Only allows "well tested, high-quality" PRs on parts of the codebase that have a low probability of causing soundness issues, and it has a seperate review process with much higher standards.

And it requires the reviewer to agree to the use of LLMs ahead of time, before the PR is opened.

IMO, it has a high likelihood of degrading to a closed system, where some programmers with a good track record have little issue merging LLM generated PRs, while anyone without a reputation will struggle to even open an ai-assisted PR.

The discussion thread in the PR is also interesting to got through, lots of people concern in the HN discussion are already well discussed there

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?

Which would favour people with fewer houses, which don't have to pay the increased taxes and so their rents could be lower.

So the 2nd, 3rd house taxes could be relatively low but for the 10th they would be ginormous.

There are very few people with that many houses anyway.

These people do not affect rents in any meaningful way.

> Small investors who owned between one and five properties held 87% of the single-family homes owned by investors; those owning six to 10 properties owned another 4%

https://www.prnewswire.com/news-releases/real-estate-investo...

Possibly but it would also create more private equity reits that would build and operate these multi-family units. There isn’t a clean solution without making it illegal for companies to own single-family homes.

You’d have to have exceptions to that. Many new homes are built as whole subdivisions, then sold to initial residential owners. Banks won’t lend on homes they can’t foreclose on as collateral, and banks are companies. Mortgage companies are for this purpose the same as banks.

Some companies buy and update homes then resell them. They don’t all do a cheap flip with a massive markup. Neither do all of them hold them long term to charge high rents. That seems like something that should probably be regulated rather than outright banned.

Beyond single-family homes, it’s very rare for someone to build an apartment building with all of the units already sold. In fact, most are not coops or condos and are rented long term. Those rents also keep going up. A big part of that is how hard it is to get a new complex, especially a mid-rise or high-rise building, permitted to build.

Incorrect about the builders. It would force builders to hold capital instead of borrowing. It would make banks able to have an asset in collateral for the loan to the person, that they can then sell. Builders already cut corners to pocket money from loan differences, we should probably put a stop to that.

I think there’s a difference between a bank company “owning” a deed vs a PE company holding it for speculation and rent squeezing. You are right though that there has to be a system to hold inventory and we made Fannie Mae and Freddy Mac macro-economic instruments instead of those inventory stewards.

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 agree with you that TP is an improvement over long lived npm tokens in CI.

However, the threat Im most afraid of still does involve dev environment compromise. Because if your repo admin gets their token stolen from their gh cli, they can trivially undo via API (without a 2fa gate!) any github level gate you have put in place to make TP safe. I want so badly to be wrong about that, we have been evaluating TP in my projects and I want to use it. But without a second factor to promote a release, at the end of the day if you have TP configured and your repo admin gets pwned, you cannot stop a TP release unless you race their publish and disable TP at npm.

TP is amazing at removing long lived npm tokens from CI, but the class of compromise that historically has plagued the ecosystem does not at all depend on the token being long lived, it depends on an attacker getting a token which doesnt require 2fa.

I am begging for someone to prove me wrong about this, not to be a shit, but because I really want to find a secure way to use TP in lodash, express, body-parser, cors, etc

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.

Not to beat the dead horse, but ths floored me when I realized it so I keep trying to shout it at the top of my lungs.

There is no gate you can put on a Trusted Publisher setup in github which requires 2fa to remove. Full stop. 2fa on github gates some actions, but with a token with the right scope you can just disable the gating of workflow-runs-on-approve, branch protection, anything besides I think repo deletion and renaming.

And in my experience most maintainers will have repo admin perms by nature of the maintainer team being small and high trust. Your point is well taken, however, that said stolen token does need to have high enough privileges. But if you are the lead maintainer of your project, your gh token just comes with admin on your repo scope.

Nobody should be routinely logged into the Admin Accounts.

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.

The way I see it - if you're pushing a change to an NPM package with more than [N] daily downloads/downstream packages, and you don't have a human online who's able to approve a two-factor for the release on their phone... then you also don't have a human online who's able to hotfix or rollback in case of a breaking bug, much less a compromise. Even setting security aside - that's in service of a stable ecosystem.

And the two-factor approver should see a human-written changelog message alongside an AI summary of what was changed, that goes deeply into any updated dependencies. No sneaking through with "emergency bugfix" that also bumps a dependency that was itself social-engineered. Stop the splash radius, and disincentivize all these attacks.

Edit: to the MSFT folks who think of the stock ticker name first and foremost - you'd be able to say that your AI migration tools emit "package suggestions that embed enterprise-grade ecosystem security" when they suggest NPM packages. You've got customers out there who still have security concerns in moving away from their ancient Java codebases. Give them a reason to trust your ecosystem, or they'll see news articles like this one and have the opposite conclusion.

That's what they're doing.