[HN Gopher] NPM Provenance Public Beta
___________________________________________________________________
NPM Provenance Public Beta
Author : justeleblanc
Score : 58 points
Date : 2023-04-19 16:36 UTC (6 hours ago)
(HTM) web link (github.blog)
(TXT) w3m dump (github.blog)
| ashishbijlani wrote:
| 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 flags risky/malicious
| NPM/PyPI/Ruby dependencies
| TechBro8615 wrote:
| 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.
| decodebytes wrote:
| better overview on the main release blog:
| https://github.blog/2023-04-19-introducing-npm-package-prove...
| jdcaron wrote:
| Yes, and second analysis by an independent party:
| https://socket.dev/blog/npm-provenance
| capableweb wrote:
| 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 wrote:
| GitHub owns NPM (And yes Microsoft owns GitHub)
| nequo wrote:
| 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 wrote:
| I suspect Microsoft prefers extending the reach of Visual
| Studio Code over acquiring JetBrains.
| capableweb wrote:
| 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 wrote:
| 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
| zdragnar wrote:
| From 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.
| johnnypangs wrote:
| 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-prove...
| [deleted]
| 9dev wrote:
| npm _is_ GitHub _is_ Microsoft.
| sublimefire wrote:
| 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/
|
| [2] https://www.nist.gov/itl/executive-order-14028-improving-
| nat...
|
| [3] https://github.com/secure-systems-lab/dsse
|
| [4] https://www.rfc-editor.org/rfc/rfc8152
|
| [5] https://github.com/in-toto/attestation
| [deleted]
| bmeck wrote:
| 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.
| jobby23 wrote:
| SCITT is pretty much just a late copy / paste of what sigstore
| has already done, save swapping out COSE for X509.
| JonChesterfield wrote:
| 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.
| kibwen wrote:
| 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 wrote:
| 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
| JonChesterfield wrote:
| Yeah, we'll see. You say paranoid, I say extinguish.
| TechBro8615 wrote:
| 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.
| JonChesterfield wrote:
| My thinking is that the path goes thus:
|
| - build on the record of supply chain compromises in npm
| to justify a provenance system
|
| - establish yourself as one of the trusted authorities on
| establishing provenance
|
| - spread fear and doubt about untrusted software
|
| - become the trusted source and supplier of software
|
| - open source becomes synonymous with untrusted software,
| basically malware
|
| - in microsoft we trust
|
| I think microsoft's land grab over open source software
| was pretty clearly established when they bought github
| and the general attitude of "they're nice now, it'll be
| fine" is going to be judged harshly in the future. Or I'm
| a paranoid crank with a misplaced mistrust of microsoft,
| who didn't declare "linux is a cancer" or anything like
| that.
| TechBro8615 wrote:
| I understand that line of thinking, but what land are
| they grabbing? They already possess all of it through npm
| and GitHub.
|
| Do you think they intend to exclude caches like
| yarnpkg.com as insecure? I don't see how they would do
| that, since (1) your cache is a local config variable,
| not part of package.json, so there's no static analysis
| that could mark packages downloaded through Yarn as
| insecure, and (2) all of the key signature metadata is
| publicly available, so any cache or alternative package
| manager can implement the same provenance features as
| npm.
|
| Or are you worried about EEE of the upstream source
| repositories and CI runners, eg "only packages built
| through GHA platform can contribute provenance data to
| npm registry?" I _guess_ I could see that as a more
| reasonable fear, but as someone else explained to you, it
| 's also unfounded (at least for now - which is maybe your
| argument), and GitLab is currently working on their own
| implementation. But even if they tried that, then you
| could still publish and consume packages from another
| registry if you wanted to. And I'd like to think that if
| Microsoft made a hostile move like that, we could count
| on package managers like yarn to pull provenance data
| from other sources.
___________________________________________________________________
(page generated 2023-04-19 23:03 UTC)