8 ms·

NPM Provenance Public Beta

67 points by justeleblanc 3y ago

decodebytes 3y ago
better overview on the main release blog: https://github.blog/2023-04-19-introducing-npm-package-provenance/ https://github.blog/2023-04-19-introducing-npm-package-prove...
- jdcaron 3y ago
  Yes, and second analysis by an independent party: https://socket.dev/blog/npm-provenance https://socket.dev/blog/npm-provenance
capableweb 3y ago
Shouldn't this be on the npmjs.com blog instead of GitHub? I know that both are owned by Microsoft, but why not use microsoft.com for everything then? Or let things at least appear separated from the outside. Edit: Oh, realize now that npmjs.com doesn't even have it's own blog/news anymore, it's been absorbed by github.blog already and link on npmjs.com redirects there. Oh well, I'll leave my comment so you all can laugh about how wrong I was.
- manojlds 3y ago
  GitHub owns NPM (And yes Microsoft owns GitHub)
  - nequo 3y ago
    It's incredible how much of the software development space is owned by Microsoft now. I wonder if they will also buy JetBrains in the foreseeable future?
    - divbzero 3y ago
      I suspect Microsoft prefers extending the reach of Visual Studio Code over acquiring JetBrains.
      - capableweb 3y ago
        I think they'd also prefer to extend the reach of C# over adopting JavaScript. But alas, reality is what reality is. Well, there is TypeScript so...
    - no_wizard 3y ago
      If the Bloomberg article[0] about them is to be believed, I don't think they're interested in being acquired [0]: https://archive.is/WeAEV https://archive.is/WeAEV
ashishbijlani 3y ago
Great work! This provenance check is going to be very valuable for enforcing supply-chain security. We are working on adding support to check for provenance in Packj. 1. https://github.com/ossillate-inc/packj https://github.com/ossillate-inc/packj flags risky/malicious NPM/PyPI/Ruby dependencies
zdragnar 3y ago
From https://docs.npmjs.com/generating-provenance-statements https://docs.npmjs.com/generating-provenance-statements In order to publish a package with provenance, you must build your package with a supported cloud CI/CD provider. Today this includes GitHub Actions, and we are collaborating with additional providers to expand support. I really hope that's not an empty statement. I enjoy some aspects of Github, but would hate to see it become the only trusted source for an entire language's ecosystem.
- 9dev 3y ago
  npm is GitHub is Microsoft.
- johnnypangs 3y ago
  If you look at the GitHub announcement in the looking ahead section it says this: > Working with other cloud CI/CD providers to add support for provenance signing So hopefully they make good on that point. https://github.blog/2023-04-19-introducing-npm-package-provenance/ https://github.blog/2023-04-19-introducing-npm-package-prove...
  - deleted 3y ago
    [deleted]
- bin_bash 3y ago
  > entire language FYI, sigstore is not js-specific
sublimefire 3y ago
FYI there is a push to standardize this stuff under the name of SCITT in IETF [1]. In this case (blog post) this is different as NPM is using in-toto attestation [5] (a description of a thing) and logs it in Google's provided append only log (transparency service). They are trying to make this thing being adopted through a freemium model at the moment. One issue here is that NIST are trying to push SBOMs [2] but NPM is not providing them as part of the provenance I think. Another thing is a push to use new types of signature envelopes like DSSE [3] instead of something like COSE [4] [1] https://datatracker.ietf.org/group/scitt/about/ https://datatracker.ietf.org/group/scitt/about/ [2] https://www.nist.gov/itl/executive-order-14028-improving-nations-cybersecurity/software-security-supply-chains-software-1 https://www.nist.gov/itl/executive-order-14028-improving-nat... [3] https://github.com/secure-systems-lab/dsse https://github.com/secure-systems-lab/dsse [4] https://www.rfc-editor.org/rfc/rfc8152 https://www.rfc-editor.org/rfc/rfc8152 [5] https://github.com/in-toto/attestation https://github.com/in-toto/attestation
- jacques_chester 3y ago
  SCITT is still nascent. Sigstore is operating and in use by multiple ecosystems. On the principle of "rough consensus and running code", SCITT is not the leader. > and logs it in Google's provided append only log This is false. The entire sigstore effort is under the OpenSSF and the production systems are operated by volunteers from multiple companies.
- bmeck 3y ago
  SBOM doesn't make sense at this level usually since the things being published lists constraints when installed locally and not locked/pinned versions. Some executables distributed on npm do provide lockfiles but those aren't SBOMs. You cannot really have an SBOM of something with unknown transitive dependencies. There are also disagreements on which SBOM would make sense here as multiple are in play.
  - lucideer 3y ago
    > Some executables distributed on npm do provide lockfiles but those aren't SBOMs Not entirely sure what this sentence means (some executables?), NPM generates lockfiles and, while lockfiles are not SPDX/CycloneDX equivalent, the overlap in intent and content is strong. SBOM makes just as much sense at this level as the existing lockfile generation mechanism.
JonChesterfield 3y ago
Thus things without provenance become unusable and Microsoft builds on ownership of npm to exert absolute control over the javascript ecosystem. I reckon I can see how this ends.
- jacques_chester 3y ago
  I hate to disappoint you, but it's actually really boring. The people who work on this stuff care about the security of NPM packages. That's the whole story.
- kibwen 3y ago
  Any code licensed under any of the popular OSS licenses are free to be hosted anywhere. If people want to mirror every package on NPM to a new registry, there's nothing Microsoft can do to stop them.
- decodebytes 3y ago
  paranoid and false. The Root CA is generated by the sigstore community (five folks, two from academia). Right now github exchanges an OIDC token for a sigstore root chained cert. GitLab are currently adding themselves, to have the same capability (several other providers are there as well). https://github.com/sigstore/fulcio/pull/1097 https://github.com/sigstore/fulcio/pull/1097
  - JonChesterfield 3y ago
    Yeah, we'll see. You say paranoid, I say extinguish.
    - TechBro8615 3y ago
      Extinguish what exactly? Are people publishing packages to anywhere other than npm, and maybe GitHub? Microsoft already owns both of those, so there is nothing to extinguish. It's not clear what you're worried about, and I'm skeptical you can articulate it, because it makes no sense. And I say this as someone who is an extremely paranoid anti-corporate crusader, just like I imagine you are. But in this instance, your worry is misplaced.
TechBro8615 3y ago
All haranguing over details aside, this is great news! I didn't know GitHub/npm was even working on this, and I'm glad to see a reasonable solution to a recognizable problem. Keep it up.
silverwind 3y ago
No, thanks. This is a massive platform lock-in. A more sane way for npm publish would be if the registry would just git checkout your repo during publish and strongly tie the package version to a commit hash.

67 points by justeleblanc 3y ago

better overview on the main release blog: https://github.blog/2023-04-19-introducing-npm-package-provenance/ https://github.blog/2023-04-19-introducing-npm-package-prove...

jdcaron 3y ago
Yes, and second analysis by an independent party: https://socket.dev/blog/npm-provenance https://socket.dev/blog/npm-provenance

capableweb 3y ago

Shouldn't this be on the npmjs.com blog instead of GitHub? I know that both are owned by Microsoft, but why not use microsoft.com for everything then? Or let things at least appear separated from the outside. Edit: Oh, realize now that npmjs.com doesn't even have it's own blog/news anymore, it's been absorbed by github.blog already and link on npmjs.com redirects there. Oh well, I'll leave my comment so you all can laugh about how wrong I was.

manojlds 3y ago
GitHub owns NPM (And yes Microsoft owns GitHub)
- nequo 3y ago
  It's incredible how much of the software development space is owned by Microsoft now. I wonder if they will also buy JetBrains in the foreseeable future?
  - divbzero 3y ago
    I suspect Microsoft prefers extending the reach of Visual Studio Code over acquiring JetBrains.
    - capableweb 3y ago
      I think they'd also prefer to extend the reach of C# over adopting JavaScript. But alas, reality is what reality is. Well, there is TypeScript so...
  - no_wizard 3y ago
    If the Bloomberg article[0] about them is to be believed, I don't think they're interested in being acquired [0]: https://archive.is/WeAEV https://archive.is/WeAEV

ashishbijlani 3y ago

Great work! This provenance check is going to be very valuable for enforcing supply-chain security. We are working on adding support to check for provenance in Packj. 1. https://github.com/ossillate-inc/packj https://github.com/ossillate-inc/packj flags risky/malicious NPM/PyPI/Ruby dependencies

zdragnar 3y ago

From https://docs.npmjs.com/generating-provenance-statements https://docs.npmjs.com/generating-provenance-statements In order to publish a package with provenance, you must build your package with a supported cloud CI/CD provider. Today this includes GitHub Actions, and we are collaborating with additional providers to expand support. I really hope that's not an empty statement. I enjoy some aspects of Github, but would hate to see it become the only trusted source for an entire language's ecosystem.

9dev 3y ago
npm is GitHub is Microsoft.
johnnypangs 3y ago
If you look at the GitHub announcement in the looking ahead section it says this: > Working with other cloud CI/CD providers to add support for provenance signing So hopefully they make good on that point. https://github.blog/2023-04-19-introducing-npm-package-provenance/ https://github.blog/2023-04-19-introducing-npm-package-prove...
- deleted 3y ago
  [deleted]
bin_bash 3y ago
> entire language FYI, sigstore is not js-specific

sublimefire 3y ago

FYI there is a push to standardize this stuff under the name of SCITT in IETF [1]. In this case (blog post) this is different as NPM is using in-toto attestation [5] (a description of a thing) and logs it in Google's provided append only log (transparency service). They are trying to make this thing being adopted through a freemium model at the moment. One issue here is that NIST are trying to push SBOMs [2] but NPM is not providing them as part of the provenance I think. Another thing is a push to use new types of signature envelopes like DSSE [3] instead of something like COSE [4] [1] https://datatracker.ietf.org/group/scitt/about/ https://datatracker.ietf.org/group/scitt/about/ [2] https://www.nist.gov/itl/executive-order-14028-improving-nations-cybersecurity/software-security-supply-chains-software-1 https://www.nist.gov/itl/executive-order-14028-improving-nat... [3] https://github.com/secure-systems-lab/dsse https://github.com/secure-systems-lab/dsse [4] https://www.rfc-editor.org/rfc/rfc8152 https://www.rfc-editor.org/rfc/rfc8152 [5] https://github.com/in-toto/attestation https://github.com/in-toto/attestation

jacques_chester 3y ago
SCITT is still nascent. Sigstore is operating and in use by multiple ecosystems. On the principle of "rough consensus and running code", SCITT is not the leader. > and logs it in Google's provided append only log This is false. The entire sigstore effort is under the OpenSSF and the production systems are operated by volunteers from multiple companies.
bmeck 3y ago
SBOM doesn't make sense at this level usually since the things being published lists constraints when installed locally and not locked/pinned versions. Some executables distributed on npm do provide lockfiles but those aren't SBOMs. You cannot really have an SBOM of something with unknown transitive dependencies. There are also disagreements on which SBOM would make sense here as multiple are in play.
- lucideer 3y ago
  > Some executables distributed on npm do provide lockfiles but those aren't SBOMs Not entirely sure what this sentence means (some executables?), NPM generates lockfiles and, while lockfiles are not SPDX/CycloneDX equivalent, the overlap in intent and content is strong. SBOM makes just as much sense at this level as the existing lockfile generation mechanism.

JonChesterfield 3y ago

Thus things without provenance become unusable and Microsoft builds on ownership of npm to exert absolute control over the javascript ecosystem. I reckon I can see how this ends.

jacques_chester 3y ago
I hate to disappoint you, but it's actually really boring. The people who work on this stuff care about the security of NPM packages. That's the whole story.
kibwen 3y ago
Any code licensed under any of the popular OSS licenses are free to be hosted anywhere. If people want to mirror every package on NPM to a new registry, there's nothing Microsoft can do to stop them.
decodebytes 3y ago
paranoid and false. The Root CA is generated by the sigstore community (five folks, two from academia). Right now github exchanges an OIDC token for a sigstore root chained cert. GitLab are currently adding themselves, to have the same capability (several other providers are there as well). https://github.com/sigstore/fulcio/pull/1097 https://github.com/sigstore/fulcio/pull/1097
- JonChesterfield 3y ago
  Yeah, we'll see. You say paranoid, I say extinguish.
  - TechBro8615 3y ago
    Extinguish what exactly? Are people publishing packages to anywhere other than npm, and maybe GitHub? Microsoft already owns both of those, so there is nothing to extinguish. It's not clear what you're worried about, and I'm skeptical you can articulate it, because it makes no sense. And I say this as someone who is an extremely paranoid anti-corporate crusader, just like I imagine you are. But in this instance, your worry is misplaced.

TechBro8615 3y ago

All haranguing over details aside, this is great news! I didn't know GitHub/npm was even working on this, and I'm glad to see a reasonable solution to a recognizable problem. Keep it up.

silverwind 3y ago

No, thanks. This is a massive platform lock-in. A more sane way for npm publish would be if the registry would just git checkout your repo during publish and strongly tie the package version to a commit hash.