6 ms·

To resolve such issues the central maven repo, for example, makes artifacts immutable when you publish them

• julianlam 5y ago
  npm does as well, they made this change after left-pad. You also can't unpublish once a single person has downloaded the package, I believe.
• mjlawson 5y ago
  This is true for npm. After the incident with leftpad, you can't unpublish anymore. You can, however, publish a new patch update that completely breaks everything.
  • throw_m239339 5y ago
    > This is true for npm. After the incident with leftpad, you can't unpublish anymore. You can, however, publish a new patch update that completely breaks everything. You absolutely can unpublish, it just requires more steps. If NPM gets a DMCA takedown request they will absolutely have to fulfill it.
    • mjlawson 5y ago
      Not only does it require more steps, it also has to meet the following criteria[1]: * no other packages in the npm Public Registry depend on * had less than 300 downloads over the last week * has a single owner/maintainer So while your point is taken that unpublishing is possible under some circumstances, it is not for popular packages that are in use today. [1] https://docs.npmjs.com/policies/unpublish https://docs.npmjs.com/policies/unpublish
      • throw_m239339 5y ago
        None of these points have any legal standing, from a copyright perspective. https://news.ycombinator.com/item?id=29868199 https://news.ycombinator.com/item?id=29868199
        • mjlawson 5y ago
          You are technically correct. The best kind of correct! In practical terms, it depends on the license used. Since most licenses used in open source will prevent you from making these kind of requests, this consequence isn't likely to have any practical implications.
          • kd5bjo 5y ago
            You are assuming that the true rights holders of all the code in the package actually agreed to the given license. Someone unrelated to the package development can still claim it includes an illegally-copied, unlicensed version of their code.
        • tomrod 5y ago
          Despite the need to keep it clear, copyright does not reign supreme.
          • throw_m239339 5y ago
            > Despite the need to keep it clear, copyright does not reign supreme. neither do NPM TOS, or whatever Microsoft thinks they are entitled to, since NPM is owned by Microsoft.
            • tomrod 5y ago
              Which is not what I argued :^)
    • dane-pgp 5y ago
      > If NPM gets a DMCA takedown request they will absolutely have to fulfill it. Assuming the package is released under a Free Software licence, what grounds would there be for a DMCA takedown? I suppose a developer could include the lyrics to a pop song in their code (possibly encrypted), and then tell the copyright holder about it (since I don't think you can make a DMCA request on behalf of a copyright holder without their permission), but I would hope that such a poison-pill would be caught long before the package became widely depended on. Perhaps you're thinking someone would risk perjury(?) charges for making a false DMCA request against their package, and NPM would act on the request without questioning it; but remember that NPM is owned by Microsoft and they have previously stood up to frivolous DMCA requests (after a fashion)[0]. That article has the lede: "Software warehouse also pledges to review claims better, $1m defense fund for open-source coders". [0] https://www.theregister.com/2020/11/16/github_restores_youtubedl/ https://www.theregister.com/2020/11/16/github_restores_youtu...
      • pc86 5y ago
        > but I would hope that such a poison-pill would be caught long before the package became widely depended on. I'm not sure what about the current open source ecosystem makes you think anyone would catch something like this.
        • zdragnar 5y ago
          Funny, my company couldn't use Webpack 1 because a dependency of a dependency... depended on an ancient package from the days when it was common to not bother with attaching a license. Legally, that meant that noone could use it. In practice, nobody but our legal department cared, so we had to wait for version 2 when the dependency chain was updated to remove it.
          • Dylan16807 5y ago
            You couldn't override the package locally? Or was too much of that code actually needed?
      • bombcar 5y ago
    • dragonwriter 5y ago
      > If NPM gets a DMCA takedown request they will absolutely have to fulfill it. No, they don't. Honoring DMCA takedowns allow benefit from an additional safe harbor from any existing infringement liability for the alleged infringing content, but are not mandatory in their own.
    • dathinab 5y ago
      Except if they have reason to believe the code was uploaded with the permission of the copyright holder. The they have gotten the right for npm to distribute the source code in context of npm.
      • throw_m239339 5y ago
        > The they have gotten the right for npm to distribute the source code in context of npm. There is absolutely no copyright or publishing right transfer that takes place when one "publishes" a package on NPM (or on Github). None. The original author is absolutely entitled to a DMCA takedown notice and NPM would have to oblige him.
        • deleted 5y ago
          [deleted]
        • mschuster91 5y ago
          You can't legally retract opening up software source code under most if not all popular open source licenses.
          • josephcsible 5y ago
            It is indeed all, even if you ignore the "popular" qualifier. If a license could be unilaterally revoked, it would fail to meet the Open Source Definition for that reason.
          • throw_m239339 5y ago
            open source =/= free software. That's the first mistake you are making.
            • josephcsible 5y ago
              While they are indeed sightly different, I fail to see how the differences are at all relevant in this context.
            • 5y ago
  • wbl 5y ago
    Why does a new version break projects without action by the project owners? In Go you would have to explicitly update to the broken version.
    • david_allison 5y ago
      *I revoke my comment. Child comment is correct.
      • K0nserv 5y ago
        That's not true. The first line of NPM install's documentation[0] says(emphasis mine): > This command installs a package, and any packages that it depends on. If the package has a *package-lock or shrinkwrap file, the installation of dependencies will be driven by that*, with an npm-shrinkwrap.json taking precedence if both files exist. See package-lock.json and npm shrinkwrap. What does happen is: if you have added a new package in package.json it will be installed based on the semver pattern specified there, or if you run npm install some-package@^x.y.z the same thing happens. Further, if you modify package.json by changing the semver pattern for an existing package that will also cause this behaviour. Running `npm install` in a package that already has a package-lock.json will simply install what's in package-lock.json. `npm install` only changes the lock file to add/remove/update dependencies when it detects that package.json and package-lock.json disagrees about the specified dependenices and their semver patterns e.g. having foo@^2.3.1 in package.json and foo@1.8.3 in package-lock.json will cause foo to be update when running `npm install`. 0: https://docs.npmjs.com/cli/v6/commands/npm-install https://docs.npmjs.com/cli/v6/commands/npm-install
    • bspammer 5y ago
      Because npm install has the insane default behavior of adding a fuzzy qualifier to your package.json, for example ^6.0.2 means all of the following versions are accepted: 6.0.2, 6.0.9, 6.7.84
      • jbverschoor 5y ago
        Welcome to JavaScript, where every division is a bad one
  • maxwell86 5y ago
    THat's why you specify the exact version of your dependencies.
  • pc86 5y ago
    You're never going to be able to prevent that at a technical level. You can prevent it with workflow, though: 1) sync packages locally and build from those versions; 2) peg to a specific version and don't auto-update; 3) deploy to a test environment and not directly to production.
• oblio 5y ago
  • detaro 5y ago
    npm also has immutable artifacts.
    • oblio 5y ago
      Yes, and my question is: why didn't they have them from day 1??? Or at least day 1000? Npm was launched in 2010, 11 years ago, and I'm quite sure immutable packages were implemented about 3 years ago. Again, this is not rocket science, we knew the attack angles.
  • stickfigure 5y ago
    You've run afoul of https://en.wikipedia.org/wiki/Poe%27s_law https://en.wikipedia.org/wiki/Poe%27s_law
    • oblio 5y ago
      The tone changes half way, it wasn't all parody, though :-) Thought it would be clear enough.
• detaro 5y ago
  How does that solve the issue here of new broken versions of packages being published?
  • oblio 5y ago
    That's another JS ecosystem widespread malpractice. Autobumping versions, or version ranges as they're called in Maven land. Dependencies should only use fixed versions and all updates should be manual. You should only use auto-upgradable versions during development, and the package manager should warn you that you're using them (or your dependencies are).
    • codebje 5y ago
      If package A depends on package C at version 1.0 but package B depends on C at version 1.1, what version of C will be pulled in? Dependency management is not as simple as only upgrading one direct dependency at a time after careful review. The NPM ecosystem is particularly difficult to work with as it has deep and broad transitive dependency trees, many small packages, and a very high rate of change. You either freeze everything and hope you don't have an unpatched vulnerability somewhere or update everything and hope you don't introduce a vulnerability somewhere.
      • throw_m239339 5y ago
        > Dependency management is not as simple as only upgrading one direct dependency at a time after careful review. Most package managers won't allow these stunts and conflicts have to be resolved UPSTREAM. NPM chose to go the "YOLO" way and will fetch every single version of a package that meets the dependency demands. Terrible design, but the purpose of that was growth for NPM, the company, not the best interest of the ecosystem.
      • oblio 5y ago
        There are package exclusions, package forcing and of course, full dependency tree checks where you review what everything pulls in. The JS ecosystem will probably have to change but because it's so decentralized, that change will be orders of magnitude harder than, for example, PHPs transition from 3 (4, 5) to 7.
• infogulch 5y ago
  Immutability feels like the best approach here. Go's module system is pretty good in this respect: "proxy" is just a proxy that serves module code, and "sum" is an append-only transparency log of the hashes of all published versions. You can't "unpublish" from the log, but you can get code hosted on proxy removed for various reasons... which users can protect themselves against by running their own proxy. Go's module version resolution strategy means that the chosen module version never changes without explicit input from the user so no "publish a new version that breaks everyone's CI" issue. All together I don't see how GP's "email php files around" is as any better than this system in any way.
• xienze 5y ago
  A key difference with Maven projects is that you specify exact dependency versions instead of “always use latest” or some variant of that, as is pretty common in the Node world.
  • dvdcxn 5y ago
    With lock files, you will always be stuck with whatever version you first installed until you explicitly ask npm to upgrade, or delete your lockfile.
  • sverhagen 5y ago
    This is not necessarily true, there are version ranges: https://www.baeldung.com/maven-dependency-latest-version https://www.baeldung.com/maven-dependency-latest-version Admittedly, I don't think it has nearly as wide a usage as it has in the NPM world. Dependabot (I know I'm not the first to mention it, here, today) is probably more of a factor. Still, it strikes me that this sort of "attack" (or mishap) is exceedingly rare in the Java ecosystem, while it's pretty common in the NPM world, and I don't immediately understand why that would be so.
    • bombcar 5y ago
      We abuse jitpack.io and MASTER-snapshot to keep out Minecraft maven builds up to date.
    • xienze 5y ago
      I was not aware of that feature. To call it rare would be an understatement I think. > while it's pretty common in the NPM world, and I don't immediately understand why that would be so. I think it boils down to Node projects typically specifying dependencies in the form “any version >= X”, effectively “always use the latest.” Dependencies can therefore get bumped silently just by rebuilding, essentially. Whereas in the Java world updating dependencies is a deliberate process.