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?

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 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