TE
科技回声
首页24小时热榜最新最佳问答展示工作
GitHubTwitter
首页

科技回声

基于 Next.js 构建的科技新闻平台,提供全球科技新闻和讨论内容。

GitHubTwitter

首页

首页最新最佳问答展示工作

资源链接

HackerNews API原版 HackerNewsNext.js

© 2025 科技回声. 版权所有。

A web of trust for NPM

143 点作者 tao_oat超过 4 年前

16 条评论

ratww超过 4 年前
I will die on that hill, so here it goes again: The problem with NPM is <i>not</i> the amount of runtime dependencies.<p>Most Javascript projects would actually fare pretty well when compared to other languages if <i>only</i> runtime dependencies were taken into account.<p>Javascript staples like React, Vue, Svelte, Typescript and Prettier actually have zero runtime dependencies. Also, the ES6 standard library is not as bad as people claim.<p>The real problem is with development dependencies. The amount of dependencies required by Babel, Webpack and ESLint are the cause for 99% of the dependency bloat we complain about in JS projects. Those projects prefer to have monorepos, but when it&#x27;s in your machine they&#x27;re splitted into tens or hundreds of dependencies. Also remember that left-pad was only an issue in 2015 because a Babel package required it. If those projects were able to get it together we wouldn&#x27;t even be having this conversation. Solve this and you&#x27;ll solve the biggest complaints people have about JS.<p>I really would like to see a discussion on this, as most people seem to put a lot of blame on JS as a whole, while it&#x27;s mostly a handful of popular projects generating <i>all</i> the complaints.
评论 #24676046 未加载
评论 #24676077 未加载
评论 #24676687 未加载
评论 #24675816 未加载
评论 #24676878 未加载
评论 #24675349 未加载
评论 #24676225 未加载
评论 #24676149 未加载
评论 #24677474 未加载
SirensOfTitan超过 4 年前
We built our app on node and typescript, and I would never choose it again at this point because of the package ecosystem. We do a lot to validate integrity of packages (including checking in vetted archives to our repo), but it’s hard. Our images are ballooned to like 500-600MB (we’ve hit past the GB mark because of certain packages messing up dependencies before) based on a pretty conservative list of dependencies because of node_modules. I’m constantly fighting a battle against image size increases. The sheer amount of files in node_modules ensures that io is always a problem for image size and build speed on CI.<p>Solutions like yarn berry hardly help: zipfs and patched tsservers is annoying in many editors still. Often packages break because package maintainers include implicit dependencies or the packages their packages depend on do so. Arc has frozen emacs for me several times when jumping to definition in a zip.<p>I’m just so over the package situation for node.
评论 #24675196 未加载
评论 #24675771 未加载
评论 #24677636 未加载
7373737373超过 4 年前
&gt; Some have argued that the ill health of the npm registry is a social, rather than a technical problem<p>In some cases it is, yes, for packages that require so many access privileges that they can subvert the entire system they run on.<p>But this is not the case for (I&#x27;d estimate) the majority of libraries, because they are purely <i>computational</i>, they only transform data and do not need access rights to any external interfaces (filesystem, network, user input, displays, ...). Malicious data generated by sandboxed programs is still a problem, still the problem would be localized.<p>There are efforts underway that would allow Javascript programs to effectively and economically sandbox each other and grant only the minimum number of privileges they need to perform their tasks: <a href="https:&#x2F;&#x2F;medium.com&#x2F;agoric&#x2F;pola-would-have-prevented-the-event-stream-incident-45653ecbda99" rel="nofollow">https:&#x2F;&#x2F;medium.com&#x2F;agoric&#x2F;pola-would-have-prevented-the-even...</a><p>Avoiding global mutable state and <a href="https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;Ambient_authority" rel="nofollow">https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;Ambient_authority</a>, being able to grant rights in an opt-in fashion and to transfer them in a way that is robust in multi-party settings in accordance with <a href="https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;Capability-based_security" rel="nofollow">https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;Capability-based_security</a><p>This is the <a href="https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;Principle_of_least_privilege" rel="nofollow">https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;Principle_of_least_privilege</a> and I encourage every language, virtual machine and operating system designer to understand it and implement it in their systems.<p>Then, the social attack surface can be technically minimized.
评论 #24674574 未加载
评论 #24674190 未加载
评论 #24674181 未加载
评论 #24674350 未加载
评论 #24674507 未加载
评论 #24674794 未加载
arkadiyt超过 4 年前
Here&#x27;s my hot take: supply chain attacks are a low risk for your organization - they are both low likelihood and low impact.<p>1) Low likelihood: when popular packages get subverted it is caught quickly due to how widely packages are distributed. After it&#x27;s caught the problem is also heavily publicized for folks to take action, and registries remove the affected versions immediately so there is a very small exposure window.<p>2) Low impact: people who write malicious code into these packages don&#x27;t have a specific target, they are writing dragnet malware, which typically means mining cryptocurrency or ransomware. If you&#x27;re going to get hacked then that&#x27;s the best possible outcome (as opposed to, e.g. a data breach).<p>Your security posture would have to be superb if supply chain attacks were anywhere near the top of your list - for the majority of companies they have more basic and targeted issues to worry about.
评论 #24674341 未加载
评论 #24674520 未加载
评论 #24674735 未加载
评论 #24674790 未加载
评论 #24674303 未加载
评论 #24674289 未加载
dane-pgp超过 4 年前
A useful step in parallel to this would be making sure that every NPM package is built from the source code that the metadata claims it is built from:<p><a href="https:&#x2F;&#x2F;hackernoon.com&#x2F;what-if-we-could-verify-npm-packages-c2a319cff758" rel="nofollow">https:&#x2F;&#x2F;hackernoon.com&#x2F;what-if-we-could-verify-npm-packages-...</a>
neil176超过 4 年前
There&#x27;s a peculiar dynamic in the npm ecosystem that folks who publish libraries naturally fully embrace the ecosystem, and thereby have a lot of other library dependencies themselves.<p>I think most engineers would not have _directly_ introduced something like left-pad into their production application dependencies since that&#x27;s something people would typically implement themselves, but people who publish open source libraries and embrace the ecosystem would gladly use someone else&#x27;s package for that since they&#x27;re also publishing with the expectation that someone will do the same with their own work.<p>It seems wrong to blame open source producers for using the work of other producers and thereby introduce a deep dependency tree, and yet the security concerns are completely valid. I personally don&#x27;t have any ideas for a solution, but it&#x27;s worth thinking about.
评论 #24675727 未加载
greggman3超过 4 年前
It&#x27;s worse than this, not NPM specifically, rather github&#x27;s atrocious permission system. Tons of github integrations ask for way to big of permissions basically allowing any of those companies, or disgruntled employees, bribed employees, breach data holders, to hack your repos.<p><a href="https:&#x2F;&#x2F;games.greggman.com&#x2F;game&#x2F;github-permission-problem&#x2F;" rel="nofollow">https:&#x2F;&#x2F;games.greggman.com&#x2F;game&#x2F;github-permission-problem&#x2F;</a><p>This isn&#x27;t just npm, it&#x27;s any dev who runs a library hosted from github who signed up to allow random 3rd parties write access to their repos. Could be C++ library, C#, a VSC plugin, a Unity asset. Tons of devs sharing code and giving out write access to that code.
offtop5超过 4 年前
The Node standard library doesn&#x27;t do enough compared to Python. Python in a locked down environment ( you can&#x27;t just install whatever you want ) isn&#x27;t bad.<p>Node is a nightmare without being able to install various packages from npm. Thus someone can remove Left Pad and it&#x27;s the end of the world. I switched from React Native to Flutter for mobile app development and it was one of the best decisions I&#x27;ve ever made
评论 #24675166 未加载
dpc_pw超过 4 年前
<a href="https:&#x2F;&#x2F;github.com&#x2F;crev-dev&#x2F;crev&#x2F;" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;crev-dev&#x2F;crev&#x2F;</a><p>People willing to help out with `npm-crev` implementation needed. :)
trollied超过 4 年前
npm needs to sort its quality issue first, but this could also be fixed with there being a better core javascript library.<p>Take <a href="https:&#x2F;&#x2F;www.npmjs.com&#x2F;package&#x2F;is-odd" rel="nofollow">https:&#x2F;&#x2F;www.npmjs.com&#x2F;package&#x2F;is-odd</a> for example. This should not be a package. Why it is even allowed to be one is insane. Do the developers importing it don&#x27;t know how to test for that themselves? Should it be part of core javascript?<p>Javascript is a mess, and npm is by extension.
评论 #24675004 未加载
alquemist超过 4 年前
Brainstorm: Could it help to run &#x27;coverage&#x27; through the web of dependencies and shake out all the code that is not explicitly exercised by an app test? Is that technically feasible? Is that cost effective?
评论 #24678377 未加载
rmrfrmrf超过 4 年前
the question of trust is the wrong question to ask imo. the bigger threat is unmaintained packages and maintainers that themselves use risky code management practices (e.g., lack of 2fa on npm). that a dependency is heavily relied on does not mean its maintainer is following best practices security-wise or that they arent just as susceptible to social engineering as anyone else.
captn3m0超过 4 年前
The strong-set of such nature doesn&#x27;t come with much guarantees beyond past-history of the said users. For eg, having commit rights to Debian requires a certain level of security know-how, being an Arch Trusted User has similar requirements (they moved to yubikeys everywhere a while back for eg).<p>We don&#x27;t even know if all these users have 2FA enabled for their NPM accounts. Building a software distribution ecosystem that offers trust guarantees post-facto is a really hard challenge, and I think that the right answer is in providing developers better sandboxes. That&#x27;s not to say this can&#x27;t be used as a signal as the author suggests, just that the &quot;strong-set-user&#x2F;package=safe&quot; guarantee doesn&#x27;t have an underlying basis as of yet.
评论 #24674793 未加载
goo6超过 4 年前
I will bet a lot of the NPM dependency problems can be solved if Node directly implemented many of the Web APIs. If PHP can implement Dom Parser, there&#x27;s no reason Node can&#x27;t implement it as well, for example.
评论 #24675556 未加载
ryan29超过 4 年前
The description of that dependency used by the BBC makes me wonder why trust is somehow based on popularity. What if the BBC got duped into using a dependency from a bad actor? Is that package trustworthy now?<p>I wonder if the package repos could come up with some type of standardized, domain verified organization namespaces. I was able to register a decent .com a couple years ago and immediately ran around registering the matching namespace everywhere. That feels a bit dumb when I have a globally unique identifier (the domain) sitting right there.<p>Why can&#x27;t I have `example.com` as my organization on NPM? I realize there would be a little complexity in domains changing ownership or being abandoned, but I feel like that&#x27;s already an issue with first come, first served namespaces. It&#x27;s just glossed over with the assumption no one will ever give away their account &#x2F; namespace which isn&#x27;t true. Is there a way to tell if an organization&#x27;s owner has changed in NPM?<p>A domain verified namespace could be on equal footing pretty quickly IMO. If it&#x27;s limited to organizations, which makes sense to me, have a requirement for the domain owner to declare the official owner of the namespace via DNS or a text file under `&#x2F;.well-known&#x2F;`. Ex:<p>npmjs._dvnamespace.example.com TXT ryan29<p>Now `ryan29` can claim or take ownership of the `example.com` organization. Every time an artifact is published, that record could be checked to ensure `ryan29` still owns the organization. If it doesn&#x27;t match, refuse to publish the artifact.<p>In effect, it&#x27;s saying &quot;example.com is delegating ultimate trust for this namespace to the user ryan29&quot;. If the domain expires, no one can publish to that namespace. If someone new registers the domain and claims the namespace by delegating trust to a new owner, that works as a good indicator that everyone pulling artifacts from the namespace should be notified there was a change in ownership.<p>It seems like a waste to me when I&#x27;m required to register a new identity for every package manager when I already have a globally unique, extremely valuable (to me), highly brandable identity that costs $8 &#x2F; year to maintain.<p>Edit:<p>To add one more thought, I&#x27;ve always been of the opinion that ultimate trust needs to resolve to an individual, not an organization. That probably needs to be done via certificates or key signing and should be done by a local organization.<p>If I could dictate a system for that, I&#x27;d use local businesses to verify ID and sign keys. For example, I&#x27;m from Canada and would love to go into Memory Express with my ID and have them sign my GPG key.<p>I don&#x27;t think you can get a real WoT like what I think was originally the intent for GPG. There are just too many bad actors these days. I think verifying identity and tying stuff back to a real person is the best you&#x27;ll get.<p>An no, I don&#x27;t want the current code signing style verification. It sucks and the incumbents are nothing more than a bunch of rent seeking value extractors.
cryptica超过 4 年前
I don&#x27;t like where this is going. Especially using number of dependents as a measure of trust. Popularity has nothing to do with trustworthiness (it just makes a problem less likely to occur, but when a problem does occur, it will be a lot worse; and npm has in fact encountered such issues in the past).<p>Just look at the real world: Is the Federal Reserve Bank a trustworthy institution? Sure, there are a lot of people using its product (the US dollar) so it&#x27;s extremely popular, but is it trustworthy? Is the product actually what its users think it is?<p>Power structures are very much the same in open source. The ecosystem has been highly financialized; a library is popular because its author has a lot of rich friends who helped them to promote it on Twitter or elsewhere. So if you don&#x27;t happen to have rich friends, does that make you untrustworthy?<p>This would lead to censorship of good projects from trustworthy people who have genuinely good intentions.<p>I think that such algorithms have done enough damage to society already.
评论 #24675257 未加载
评论 #24675691 未加载