23 replies

1. Zach Leatherman Bluesky moments later

   maybe a cheeky and very optional cc to @notwes.bsky.social

   1. Wes Bluesky 2 hr later

      There is no way today.

      1. Wes Bluesky 2 hr later

         One of the many gaps I’ve been asking them to fill.

         1. Wes Bluesky 2 hr later

            Despite me saying that providence is completely pointless, if they are going to push this then they should at least do it right.

            1. Wes Bluesky 2 hr later

               Joking aside, the reason they can’t enforce this is because there’s a whole bunch of gaps in the way that the system works. It’s why most of the folks who tried publishing with providence had to disable it in some cases.

               Even the new pnpm feature is not easily turned on for many repos.

2. castastrophe Mastodon 10 min later

   @zachleat Could you add a check to the prepublishOnly command? https://docs.npmjs.com/cli/v7/using-npm/scripts#:~:text=for%20more%20info.-,prepublishOnly,-Runs%20BEFORE%20the

   1. castastrophe Mastodon 12 min later

      @zachleat The prepare command doesn't run on --dry-run so possibly that's a better place to hook?

   2. Zach Leatherman Mastodon 13 min later

      @castastrophe ah, yeah — I am mostly thinking about security footprint here. If a token is compromised, this might help prevent malicious code (because it would need that code to exist in the repo too)

3. Jeppe Reinhold 🇩🇰 Bluesky 3 hr later

   If you have Trusted Publishing enabled and enforced, which attack vector are you trying to guard against here?

   1. Zach Leatherman Bluesky 4 hr later

      as far as I can tell, you can use Trusted Publishing *without* Provenance. so if your CI is compromised, an attacker could still publish untracked malicious code, no? I want all of the code published to have a “paper trail” tied to GitHub commits

      docs.npmjs.com/trusted-publ...

      1. Wes Bluesky 4 hr later

         There is at least one case it is required to be turned off when used with OIDC/TP: when the name of the package does not match the repo name.

         At least this was true last month, I haven't tested again since.

         1. Wes Bluesky 4 hr later

            > I want all of the code published to have a “paper trail” tied to GitHub commits

            FWIW, you have always had this:

            curl registry.npmjs.com/@11ty/eleventy | jq '.versions["3.1.2"].gitHead'

            1. Wes Bluesky 4 hr later

               What provenance adds is theater on top of this. Not only does it add nothing to verify the reproducibility of that tarball from that git commit, it only stores a link to the GHA that built it which expires after 90 days.

               1. Zach Leatherman Bluesky 4 hr later

                  I see what you mean, especially if you’re doing a lot of prepublish transpilation (et al).

                  I’m curious if _requiring_ provenance would be good enough to fix most of the big leaks in simpler projects. (I also wonder separately if TP would have been better without the option to disable provenance?)

                  1. Wes Bluesky 4 hr later

                     The stuff is hard to go into detail over posts here. But the TLDR is neither providence nor trusted publishing fix the root of the problems that have been leading to our recent spree of attacks.

                     Enforcing 2FA would.

                     1. Wes Bluesky 4 hr later

                        The automated publishing attacks have relied on two things:

                        - Local tokens
                        - compromised CI

                        Those only apply to the second, and if you compromise the CI you can publish *from* the CI with provenance and TP checked passing.

                        1. Wes Bluesky 4 hr later

                           It changes the attack, but it doesn’t fix it.

                           1. Wes Bluesky 4 hr later

                              And for local publishing you can enforce 2FA. Which is explicitly not allowed with trusted publishing “by design”.

               2. Tim Perry Bluesky 4 hr later

                  Is it? Seems like the npm metadata is user controlled (a nice signal, little more) while TP provenance does give some guarantee (backed by GitHub) that the code at the recorded commit hash generated the output.

                  Stores the commit hash as well, so GHA history would be nice but not strictly necessary.

                  1. Wes Bluesky 4 hr later

                     It’s definitely somewhat different, and if it was implemented differently, it could provide a stronger signal.

                     1. Wes Bluesky 4 hr later

                        We’ve had a bunch of public conversations about this topic, and I’m not gonna rehash years of context every time this discussion comes up on here.

                        1. Wes Bluesky 4 hr later

                           The theory is great. What shipped is an incomplete and often misleading mess. I have used the above method for the past four years responding to real security incidents.

                           Not once has providence helped, and trusted publishing has removed one critical feature rely on (the publishing user).

                           1. Wes Bluesky 4 hr later

                              The first time that they githead is spoofed I will absolutely change my opinion on this. But that has not happened once that I have seen.