We All Dodged a Bullet

The only real solution is to have domain-bound identities like passkeys.

Absolutely. A lot of developers work on a large Enterprise app for years and then scoot off to a different project or company.

What's not fun is being the poor Ops staff that have to deal with supporting the library dependencies, JVM upgrades, etc for decades after.

https://blog.plan99.net/why-not-capability-languages-a8e6cbd...

    function main(io) {
        const result = somethingThatRequiresHttp(io.fetch);
        // ...
    }

    function main(io) {
      const result = something(readonlyFetch(onlyOurAPI(io.fetch))
    }
    function onlyOurAPI(fetch) {
      return (...args) => {
        const test = /^https:\/\/api.mydomain.example\//.exec(args[0]);
        if (test == null) {
          throw new ValueError("must only communicate with our API");
        }
        return fetch(..args);
      }
    }
    function readonlyFetch(fetch) { /* similar but allowlist only GET/HEAD methods */ }

Shoutout to Ryan Dahl and Deno, where you write `#!/usr/bin/env deno --allow-net=api.mydomain.example` at the start of your shell script to accomplish something similar.

In my amateur programming-conlang hobby that will probably never produce anything joyful to anyone other than me, one of those programming languages has a notion of sending messages to "message-spaces" and I shamelessly steal Doug's idea -- message-spaces have handles that you can use to communicate with them, your I/O is a message sent to your main m-space containing a bunch of handles, you can then pattern-match on that message and make a new handle for a new m-space, provisioned with a pattern-matcher that only listens for, say, HTTP GET/HEAD events directed at the API, and forwards only those to the I/O handle. So then when I give this new handle to someone, they have no way of knowing that it's not fully I/O capable, requests they make to the not-API just sit there blackholed until you get an alert "there are too many unread messages in this m-space" and peek in to see why.

There’s no reason a color parser, or a date library should require network or file system access.

And at least with a standardized package manager, the packages are in a standard format that makes them easier to analyze, audit, etc.

Same with Java, if you avoid springboot and similar everything frameworks, which admittedly is a bit of an uphill battle given the state of java developers.

You can of course also keep dependencies small in javascript, but it's a very uphill fight where you'll have just a few options and most people you hire are used to including a library (that includes 10 libraries) to not have to so something like `if (x % 2 == 1)`

Just started with golang... the language is a bit annoying but the dependency culture seems OK

You don't have to believe me, read the links.

They have it implemented.

I created NPM account today and added passkey from my laptop and hardware key as secondary. As I have it configured it asked my for it while publishing my test package.

So the guy either had TOTP or just the pw.

Seems like should be easy to implement enforcement.

Cool, get big enough, become friends with the right people and you can squat an entire name on the internet. What, you're the Nepalese Party for Marxists, you've existed for 70 years and you want to buy npm.np ? Nope, tough luck, some random dude pushes shitty javascript packages over there. Sorry for the existing npm.org address too, we're going to expropriate the National Association of Pastoral Musicians. Dare I remind you that the whole left-pad situation was because Kik, the company, stole (with NPM's assistance because they were big enough and friends with the right people) the kik package ?

At least they're paying dozens of millions to buy a shitty ass .google that noone cares about because more and more browsers are hiding the URL bar. I'm glad ICANN can use it to buy drinks, hookers instead of being useful.

A week later some executive pushing the training emailed the entire company saying that it was unacceptable that nobody from engineering had logged into the training site and spun some story about regulatory requirements. After lots of back and forth they still wouldn't accept that it obviously looked like a phishing email.

Eventually when we actually did the training, it literally told us to check the From address of emails. I sometimes wonder if it was some weird kind of performance art.

Title: "Expense report overdue - Please fill now"

Subject:

<empty body>

<Link to document trying it's best to look like google's attachment icon but was actually a hyperlink to a site that asked me to log in with my corporate credentials>

---

So like, obviously this is a stupid phishing email, right? Especially as at this time, I had not used my corporate card.

A few weeks later I got the finance team reaching out threatening to cancel my corporate card because I had charges on it with no corresponding expense report filed.

So on checking the charge history for the corporate card, it was the annual tax payment that all cards are charged in my country every year, and finance should have been well aware of. Of course, then the expense system initially rejected my report because I couldn't provide a receipt, as the card provider automatically deducts this charge with no manual action on the card owner's side...

Edit: nvm it seems it's not the case

The link went to the same domain as the From address. The URL scheme was 1:1 identical to the real npm's.

> but, ok, you click the link, you get a new tab, and you're asked to fill in your auth credentials. but why? you should already be logged in to that service in your default browser, no? red flag 2

Why wouldn't I be? I don't stay logged into npm at all.

Better defense would be to delete or quarantine the compromised versions, fail to build and escalate to a human for zero-day defense.