jonchurch_

In case anyone gets to learn this today…

You can have customers without product market fit.

A product that hasnt found PMF could be a solution looking for a problem, or it might solve a true problem but that problem isn't important, durable, or (crucially) common enough to sustain a business.

So OP was saying that Lightstream Studios made some great stuff, but that ultimately the problem they were solving wasnt durable or widespread enough for the market to sustain the business they had built.

Background on Lighstream Studios is they did a streamer setup in the cloud, so you didnt have to run OBS locally. A lot of people seemed to want that at the time, especially console gamers, but the market changed around them. Consoles are way better at streaming without any other stuff now, and PC gamers largely settled on running OBS (for free) on their own existing hardware. They had like 17k paying customers at one point, so customers wasnt the smoking gun here.

caffeinate -is -t 7200 claude --remote-control

then Control + Command + Q ftw

(keep system from sleeping if plugged in, keep system from going idle even if not plugged in, for 2 hours, start claude code w/ remote control enabled, lock my mac w/ the keyboard shutcut)

npm v12 released last month also defaults into blocking them by default

Im curious OP, what was the specific callsite (not overall category) that made you write this library? What did the code look like before/after you used this library?

And in that callsite, what were you doing with the resolved value?

Came to say this, ICANN says:

“This status code is set by your domain's Registry Operator. Your domain is not activated in the DNS.”

Also the serverDeleteProhibited status is active, which ICANN also admits is a weird and rare one:

“This status code prevents your domain from being deleted. It is an uncommon status that is usually enacted during legal disputes, at your request, or when a redemptionPeriod status is in place.”

https://www.icann.org/resources/pages/epp-status-codes-2014-...

Edit: I didnt even notice until someone pointed out this was on the Nex-n2 repo not the rio one, now I understand the OP’s confusion!

It wasnt framed as an issue which is the norm breakage I think you’re reacting to, as in they didnt ask that the readme be updated etc, but it is common now for folks to use a project’s issue tracker to name and shame them in a place they cant easily ignore.

Whether that’s right, prosocial, or professional is up for debate (as well as if any single definition of etiquette can be expected in 2026 on an issue tracker).

But surely you can see the optics reason why someone would take their complaint to the repo directly? It pressures the maintainers to respond, it allows for a pile on from the internet, and makes any decision to lock down a hostile thread into its own kind of statement.

The maintainers should absolutely post an official response and lock the thread though, it will likely get ugly in there.

(2021)

I am so incredibly stoked to see this! It is the piece which can FINALLY make it so Trusted Publishing can be safely used.

This releases a lot of pressure on maintainers, who until now needed to be experts in securing CI infrastructure in order to reduce the risks inherent in TP being a step backwards compared to local publishing with a second factor.

Will it be perfect? No, Im inclined to think nothing is perfectly secure. But I believe this will go a long way towards improving our ecosystem’s posture against at least the attack vectors we are seeing today.

The compromised action here was using pnpm.

They poisoned the github action cache, which was caching the pnpm store. The chain required pull_request_target on the job to check bundle size, which had cache access and poisoned the main repo’s cache

The malicious package that was publisjed will compromise local machines its installed in via the prepare script, though.

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.

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

I tested approving a deployment via API last week w/ my gh cli token (well, had claude do it while I watched). Again, I really want to be wrong about this, but my testing showed that it is indeed trivial to use the default token from my gh cli to approve via API. (repo admin scope, which I have bc I am admin on said repo)

Nothing in this link [1] proves what I said, but it is the test repo I was just conducting this on, and it was an approval gated GHA job that I had claude approve using my GH cli token

I also had claude use the same token to first reconfigure the enviornment to enable self-approves (I had configured it off manually before testing). It also put it back to self approve disabled when it was done hehe

[1] https://github.com/jonchurch/deploy-env-test/actions/runs/25...

I have not read that blog post. But unfortunately (and I'd love to be wrong!) it doesn't matter for if a repo admin's token gets exfiled, because if you put your gates within Github, an admin repo token is sufficient to defang all of them from the API without 2fa challenge.

That is why I want 2fa before publish at the registry, because with my gh cli token as a repo admin, an attacker can disable all the Github branch protection, rewrite my workflows, disable the required reviewers on environments (which is one method people use for 2fa for releases, have workflows run in a GH environment whcih requires approval and prevents self review), enable self review, etc etc.

Its what I call a "fox in the hen house" problem, where you have your security gates within the same trust model as you expect to get stolen (in this case, having repo admin token exfiled from my local machine)

its so wild to have seen this advice reverse course over the past year.

it used to be that projects that pinned deps were called out as being less secure due to not being able to receive updates without a publish.

different times, different threat model I suppose

It is unfortunate, but this is evidence (IMO) that Trusted Publishing is still ~~not secure~~ not enough by itself to securely publish from CI, as an attacker inside your CI pipeline or with stolen repo admin creds can easily publish. This isnt new information, TP is not meant to guarantee against this, but migrating to TP away from local publish w/ 2fa introduces this class of attack via compomise of CI. (edit: changed "still not secure" to "still not enough by itself" bc that is the point I want to make)

Going to Trusted Publishing / pipeline publishing removes the second factor that typically gates npm publish when working locally.

The story here, while it is evolving, seems to be that the attacker compromised the CI/CD pipeline, and because there is no second factor on the npm publish, they were able to steal the OIDC token and complete a publish.

Interesting, but unrelated I suppose, is that the publish job failed. So the payload that was in the malicious commit must have had a script that was able to publish itself w/ the OIDC token from the workflow.

What I want is CI publishing to still have a second factor outside of Github, while still relying on the long lived token-less Trusted Publisher model. AKA, what I want is staged publishing, so someone must go and use 2fa to promote an artifact to published on the npm side.

Otherwise, if a publish can happen only within the Github trust model, anyone who pwns either a repo admin token or gets malicious code into your pipeline can trivially complete a publish. With a true second factor outside the Github context, they can still do a lot of damage to your repo or plant malicious code, but at least they would not be able to publish without getting your second factor for the registry.

> So when Becker asked ChatGPT (at the time of writing his book, it has been updated since)

Instead HN has human moderators, who often make changes in response to these kinds of things being pointed out. Which is quite a luxury these days!

Thats what the second chance pool is for

The guidelines talk about primary sources and story about a story submisisons https://news.ycombinator.com/newsguidelines.html

Creating a new URL with effectively the same info but further removed from the primary source is not good HN etiquette.

Plus this is just content marketing for the ai security startup who posted it. Theyve added nothing, but get a link to their product on the front page ¯\_(ツ)_/¯

This article only rehashes primary sources that have already been submitted to HN (including the original researcher’s). The story itself is almost a month old now, and this article reveals nothing new.

The researcher who first reported the vuln has their writeup at https://adnanthekhan.com/posts/clinejection/

Previous HN discussions of the orginal source: https://news.ycombinator.com/item?id=47064933

https://news.ycombinator.com/item?id=47072982

Hey, thank you kind strangers who sent me some money. I appreciate it! <3

> How many total developers does that cover? 100?

I love these questions bc they both can be answered with some slight heuristics, and they are quite surprising!

As of January 2026, there were > 13k npm packages w/ more than 1 Million monthly downloads [1]

Answering "how many total developers does that cover" is a lot harder (more expensive, rather, as I am not going to pay for the query on Google BigQuery to answer it, not after I spent $3k by accident last time doing similar exploration in the past)

I wont try to make a SWAG about how many devs have write access across those repos, but in the npm ecosystem alone I'm comfortable saying it is an order of magnitude more than 100.

[1] - https://gist.github.com/jonchurch/1dd845f4d26823fce5590af1aa...

ETH address 0x60F9CC1b97C78D8E8337Ef991a34bd8D9e600420 ¯\_(ツ)_/¯

I currently pay them $200/month out of my own pocket for this already, so for me it is not a free trial but subsizing my usage.

Agreed that $200 USD would be preferable (credits dont pay rent). My comment is directed at the strong words others have left about this being in bad faith on the whole. Even if it is, then their bad faith efforts are better than most.

Opinions here will vary, I wanted to share mine <3

I dont want to misrepresent, I am not the original author of any of these projects. I am not JDD of lodash (who is still involved and part of the TC) nor TJ Holowaychuk of express.

I dont know what the future will look like, but IMO open source is the intersection of code and community (aka the squishy bits) and for that reason I dont think AI will make it obselete, not now nor in the future.

Folks saying this offer is in bad faith or not generous enough dont seem to understand how low the bar is here for rewarding maintainers.

I maintain Express.js and Lodash, as well as a number of express direct deps (as a TC member of both Express and Lodash).

OSS has been my fulltime focus for over a year (aka Im unemployed). In 2025 I made $10 from open source, in the form of an amazon gift card for fixing a bug in another random open source project (I think they have VC money).

Call it skill issue on my part, sure valid. But having a form that says “give us your email and handle, we can easily verify your contributions, and in exchange you get $200/month of value and we ask nothing of you” is the most generous gift Ive seen.

Is it enough to fix the well known power dynamics of OSS? Of course not. Is it cheap PR for Anthropic? Yes, as is every other corporate OSS fund initiative. Im not going to give them a standing ovation and a key to the city bc they cleared the extremely low bar.

My point is that, regardless of motives, from this maintainer’s perspective this is a kind offer which is respectful of me and my time. If you fall into the camp that training on OSS is stealing, I can see why youd think that this is a slap in the face. I personally do not see it that way, as my work is a conduit for me to serve millions Ill never meet, and what they do with my labor is not a personal concern. I do what I do because the process itself has value to me.

Wow very cool, theyve now closed 150 bugs identified via ai assistance/static analysis!

For ref, here is the post from Joshua Rogers about their investigation into the tooling landscape which yielded those findings

https://joshua.hu/llm-engineer-review-sast-security-ai-tools...

Daniel Stenberg of curl gave a talk about some of what theyve been experiencing, mostly on the security beg bounty side. A bit hyperbolic, and his opinion is clear from the title, but I think a lot of maintainers feel similarly.

“AI Slop attacks on the curl project” https://youtu.be/6n2eDcRjSsk

You can churn this stuff out in about an hour these days though, seriously. Thats part of the problem, the asymmetry of time to create vs time to review.

If I can write 8 9k line PRs everyday and open them against open source projects, even closing them let alone engaging with them in good faith is an incredible time drain vs the time investment to create them.

We are seeing a lot more drive by PRs in well known open source projects lately. Here is how I responded to a 1k line PR most recently before closing and locking. For context, it was (IMO) a well intentioned PR. It purported to implement a grab bag of perf improvements, caching of various code paths, and a clustering feature

Edit: left out that the user got flamed by non contributors for their apparently AI generated PR and description (rude), in defense of which they did say they were using several AI tools to drive the work. :

We have a performance working group which is the venue for discussing perf based work. Some of your ideas have come up in that venue, please go make issues there to discuss your ideas

my 2 cents on AI output: these tools are very useful, please wield them in such a way that it respects the time of the human who will be reading your output. This is the longest PR description I have ever read and it does not sound like a human wrote it, nor does it sound like a PR description. The PR also does multiple unrelated things in a single 1k line changeset, which is a nonstarter without prior discussion.

I don't doubt your intention is pure, ty for wanting to contribute.

There are norms in open source which are hard to learn from the outside, idk how to fix that, but your efforts here deviate far enough from them in what I assume is naivety that it looks like spam.