If you can change a GitHub Actions workflow to exfiltrate a token, what prevents you from changing the workflow that uses Trusted Publishing to make changes to the package before publishing it? Perhaps by adding an innocent looking use of an external Action?
In general, yes, it is easier to exfiltrate the token because if you can control some of the code that runs with the token available as an env var, you can do whatever.
In the specific case of the attack described in the blog post, though, the attackers added an extra GitHub Actions workflow that sent the token to an external server. That means they had enough privileges to change GHA workflows, and could just as easily change a workflow that used Trusted Publishing.
(It may be possible to configure branch protections or rules limiting who/when can trigger the Trusted Publishing workflow, but it's about as difficult as limiting the secret tokens to only be available to some maintainers.)
Is there any way to install CLI tools from npmjs without being affected by a recent compromise?
Rust has `cargo install --locked`, which will use the pinned versions of dependencies from the lockfile, and these lockfiles are published for bin packages to crates.io.
But it seems npmjs doesn't allow publishing lockfiles, neither for libraries nor for CLI tools, so if you try to install let's say @google/gemini-cli, it will just pull the latest dependencies that fit the constraints in package.json. Is that true? Is it really this bad? If you try to install a CLI tool on a bad day when half of npmjs is compromised, you're out of luck?
Lock files wouldn't work if they were locking transitive dependencies; otherwise the version solver would not have any work to actually do and you'd have many, many versions of the same package rather than a few versions that satisfy all of the version range constraints.
Lots of good ideas since last week, the one I like most being that published packages, especially those that are high in download count, don't actually go publish for a while until after publishing, allowing security scanners to do their thing.
In the Rust ecosystem, you only publish lock files for binary crates. So yeah then you get churn like https://github.com/cargo-bins/cargo-binstall/releases/tag/v1... bumping transitive deps, but this churn/noise doesn't exist for library crates - because the lock file isn't published for them.
That Cargo.lock will only be used for the library's own CI though (and also for development if you git clone it). It will not be used by downstream dependencies at all.
npm will use your lockfile if it’s present, otherwise yeah it’s pretty much whatever is tagged and latest at the time (and the version doesn’t even have to change). If npm respected every upstream lockfile, then it could never share a single version that satisfied all dependencies.
The bigger issue here is that npm has such unrestricted and unsupervised access to the entire environment at all.
> If npm respected every upstream lockfile, then it could never share a single version that satisfied all dependencies.
I'm asking in the context of installing a single CLI tool into ~/bin or something. There's no requirement to satisfy all dependencies, because the only dependency I care about is that one CLI tool. All I want is an equivalent of what `cargo install --locked` does — use the top-level lockfile of the CLI tool itself.
That sounds pretty reasonable: npm should allow bundling the lockfile with things that are marked with the type of "project", and whether it actually uses them depending on whether other locked constraints are overriding it. So instead of one lockfile, a prioritized list of them. The UX of dealing with that list could be a sticky wicket though, and npm isn't known for making this stuff easy to begin with.
npm itself does not know that what you are installing is a CLI tool.
Good CLI tools are bundled before release so they are zero-dependency as far as npm is concerned, which is ideal imho for all CLI tools, but many don't do that.
Looking for "type": "project" is about as close as npm gets to knowing whether something is a command, but lots of libraries do ship with utility commands. npx knows, since it's used for nothing but commands. I've never seen bundling used for anything I've installed through npm; that's more likely for standalone downloads and possibly things like homebrew.
I'll repeat that the bigger problem is that npm has such unfettered access to everything in the user account to begin with. FSM knows it's not strictly an npm problem, it's a Unix problem that's been there since the beginning, just that now, enough of the chickens are coming home to roost that people are starting to notice.
Yes, right now it's mostly just wifi at stations only. However, they're deploying 4G/5G coverage in the tunnels and expect 80% coverage by the end of 2024 [1].
So… you can expect apps developed by engineers in London to get much worse on slow internet in 2025. :-)
Try using KOReader instead of the built-in reader software. It's a bit faster (doesn't wait to reflow the entire book if you change fonts, margins, orientation, whatever), and also it's easier to achieve consistent rendering of books (fonts, spacing, etc.) as it supports overriding the stylesheet, and just generally handles HTML/CSS better.
Oh, and speaking of responsiveness, I found that it depends on temperature a lot. E-ink apparently has a sweet spot at room temperature, but when I use the device outdoors, in either sub 10 ˚C temperatures or over 30 ˚C the screen changes noticeably slower.
I don't believe you're correct. It seems like the option that Debian decided on _will_ remove those features for users who are upgrading a package.
Users who already have the keypassxc package will need to explicitly switch packages if they want the full one. That's not the same behaviour as described in my quote comment.
Right, I should have been more careful with the word "exactly". I don't think the proposed solution can be implemented, though.
If the "keepassxc" package is to be replaced by the two alternatives ("keepassxc-full" and "keepassxc-minimal"), you'd still need a transitional dummy package named "keepassxc". That package would depend on "keepassxc-full | keepassxc-minimal", giving the user a choice to satisfy the dependency by installing either of those. So far so good. What if the user doesn't explicitly choose, though? The idea is that an upgrade would keep the "-full" variant but "apt install keepassxc" would pull in the "-minimal" variant. How do you encode this in Debian package metadata?
I think both "apt install" and "apt full-upgrade" will simply choose the first alternative, so you get either "-full" in both scenarios, or "-minimal" in both.
