5 ms·

I'll rather use a really small, static (as in never changing) package then something bloated that get updates every day and breaking changes from time to time.

by z3t4 5y ago

I'll rather use a really small, static (as in never changing) package then something bloated that get updates every day and breaking changes from time to time. left-pad was not the problem. The problem was that NPM changed ownership of already existing package-names - which caused the left-pad owner to remove his packages in protest.

konschubert 5y ago
Maybe published package versions should be immutable. I get the malware concerns but in practice I don't think they are such a big blocker.
- codesections 5y ago
  > Maybe published package versions should be immutable. They are in many languages. Of those I'm familiar with, Raku, Rust, and JavaScript all have immutable package repos. (npm wasn't when left-pad was pulled but has changed since then). Of course, in each case they're only "immutable" in the sense that some organization (with varying degrees of centralization) has promised to host them forever; people clearly vary in their willingness to believe promises of that nature.
  - DarylZero 5y ago
    Haskell's Stack and Nix have immutable repositories in a more technical sense: you can specify the entire set of dependencies using cryptographic hashes of their contents.
    - iudqnolq 5y ago
      Other package managers also store hashes, just separately in lock files. The main issue is a takedown for legal or administrative reasons. If you have a hash that might possibly be helpful in searching for an alternative source after a takedown, but it's not that much protection
- simion314 5y ago
  >Maybe published package versions should be immutable. Still won't help you if the leftpad dev wanted to send a message/protest could have put a small update that would do something bad. The problem is when you are not the idiot that installs leftpad but you need to install some other package like some GUI or testing framework and those "smart" devs decided to depend on leftpad directly or indirectly because some stupid philosophy. I have inherited a project with such kind of idiotic dependencies , inlcuding small stupid shit or packages with incorrect package.json that depend on things they do not actually depend or things they should not .
  - konschubert 5y ago
    It would help if you use a lock file and/or pin to badges of dependency versions.
    - simion314 5y ago
      Yeah, but I never seen people locking the dependencies to an exact version, probably to get small fixes and important security ones. But then you still have issues with packages depend on npm website existing in future or even some packages are just linking to a git repo directly so if the repo is gone or giuthub is gone you(or others) can't re-create your project.
      - codesections 5y ago
        > I never seen people locking the dependencies to an exact version This depends heavily on the language/ecosystem. For example, golang's Minimal Version Selection[0] basically requires libraries to specify an exact version – the only way they'd get a higher one is if another library in the dependency graph had manually upgraded to the higher version. But yeah, if the source is hosted externally and you don't have a local copy somewhere, then that's going to hurt. Which is (part of) why "should I vendor my dependencies" is such a perennial topic. [0]: https://research.swtch.com/vgo-mvs https://research.swtch.com/vgo-mvs
        5y ago
codesections 5y ago
> I'll rather use a really small, static (as in never changing) package [instead of one] that get updates every day and breaking changes from time to time. That's an entirely fair point and, as I got into a bit in the versioning[0] section, something that I'm giving a good deal of thought too. I'm currently leaning towards tracking the Rakudo[1] compiler releases (~monthly), so updates wouldn't be anything like daily. As far *breaking* changes go – well, again, I'm still thinking about/discussing what guarantees to make, but I'm hoping to be able to promise to (try to) provide strong backwards compatibility. One thing I mentioned in the post is that Raku's strong support for multiple dispatch[2] makes backwards compatibility a bit easier: `_` can add a new version of a function without impacting the existing one. That still leaves _accidental_ breakage (i.e., bugs) – which is the area I'm currently most concerned about. If not handled correctly, a utility package risks creating its own sort of internal dependency hell: if there's a bug in one sub-package that you use, it could potentially block you from using that version – even if a different sub-package has a feature you want. I'm not sure of the best solution yet, but I'm exploring a few Raku options that I think may let me provide versions at the sub-package level (or maybe even the function level?). That's very much a WIP for now, but it's something that'll happen before a 1.0.0 release. [0]: https://raku-advent.blog/2021/12/11/unix_philosophy_without_leftpad_part2/#versioning https://raku-advent.blog/2021/12/11/unix_philosophy_without_... [1]: https://rakudo.org/ https://rakudo.org/
masklinn 5y ago
> The problem was that NPM changed ownership of already existing package-names - which caused the left-pad owner to remove his packages in protest. And of course that npm allowed unilaterally pulling packages and breaking all dependents.
HPsquared 5y ago
In this vein, for particularly sensitive applications (e.g. password managers) I prefer to disable automatic updates.
- jasonpeacock 5y ago
  How do you identify when to perform updates for security reasons?
  - wincent 5y ago
    I think poster is saying turn _off_ "Automatically install updates" but leave _on_ "Check for updates [Daily/Weekly/Monthly]". That way you at least become aware that updates are available, and can assess them for yourself.
eternityforest 5y ago
Those large libraries don't change either, if you use a fixed version. Security updates are important, but it's not like CVEs are particularly common in 5 functions like left-pad, and bloated code that isn't reachable in your app is probably not going to be an attack surface. Especially if a dead code remover gets it.
- dundarious 5y ago
  JDNI was "dead code" for almost everybody, in that nobody intentionally used or wanted it. Unfortunately it was really just "dormant code" waiting to wake up. There is a dial from small to large (in terms of code size or feature set), static or growing feature set, pinned to floating dependencies (if you are notified on available updates to your pinned version and review them, which is actually possible for small dependencies, it's largely equivalent to floating). I don't think anyone is going to be able to convincingly say "my choice of large, growing, floating is best", or even though it's my starting preference, convincingly say "small, static, pinned is best". If you don't have the features or performance you need yet, you can make a good choice in picking a growing, floating dependency -- your call. But there is absolutely in my mind a need for greater general discipline in dependency capabilities. We don't need a monad stack or effects system in order to say "you can't add code to remote download, deserialize, and execute, in a call to log, that's just not a sensible thing to do". Or maybe we do, because much of us still haven't learned this lesson.
  - b3morales 5y ago
    It doesn't apply universally, but in front end development a large part of the problem is that engineering is not, in practice, the ultimate decider for (all) dependencies. The business/product side often dictates integration with a particular third-party service; those services don't have an option to not use their own SDK, and the SDK itself may come with its own dependencies. To the business side, security risk looks abstract, theoretical, and easy to "it can't happen to me", especially compared to whatever goal is tied to the integration. Facebook in mobile applications is a perfect example. Not a security issue, but the two crash incidents last year caused some havoc for iOS developers. But as far as I am aware the only way to get Facebook login in your mobile app is to use the SDK, and no product manager on the planet is going to let engineering talk them out of Facebook user support.

by z3t4 5y ago

konschubert 5y ago

Maybe published package versions should be immutable. I get the malware concerns but in practice I don't think they are such a big blocker.

codesections 5y ago
> Maybe published package versions should be immutable. They are in many languages. Of those I'm familiar with, Raku, Rust, and JavaScript all have immutable package repos. (npm wasn't when left-pad was pulled but has changed since then). Of course, in each case they're only "immutable" in the sense that some organization (with varying degrees of centralization) has promised to host them forever; people clearly vary in their willingness to believe promises of that nature.
- DarylZero 5y ago
  Haskell's Stack and Nix have immutable repositories in a more technical sense: you can specify the entire set of dependencies using cryptographic hashes of their contents.
  - iudqnolq 5y ago
    Other package managers also store hashes, just separately in lock files. The main issue is a takedown for legal or administrative reasons. If you have a hash that might possibly be helpful in searching for an alternative source after a takedown, but it's not that much protection
simion314 5y ago
>Maybe published package versions should be immutable. Still won't help you if the leftpad dev wanted to send a message/protest could have put a small update that would do something bad. The problem is when you are not the idiot that installs leftpad but you need to install some other package like some GUI or testing framework and those "smart" devs decided to depend on leftpad directly or indirectly because some stupid philosophy. I have inherited a project with such kind of idiotic dependencies , inlcuding small stupid shit or packages with incorrect package.json that depend on things they do not actually depend or things they should not .
- konschubert 5y ago
  It would help if you use a lock file and/or pin to badges of dependency versions.
  - simion314 5y ago
    Yeah, but I never seen people locking the dependencies to an exact version, probably to get small fixes and important security ones. But then you still have issues with packages depend on npm website existing in future or even some packages are just linking to a git repo directly so if the repo is gone or giuthub is gone you(or others) can't re-create your project.
    - codesections 5y ago
      > I never seen people locking the dependencies to an exact version This depends heavily on the language/ecosystem. For example, golang's Minimal Version Selection[0] basically requires libraries to specify an exact version – the only way they'd get a higher one is if another library in the dependency graph had manually upgraded to the higher version. But yeah, if the source is hosted externally and you don't have a local copy somewhere, then that's going to hurt. Which is (part of) why "should I vendor my dependencies" is such a perennial topic. [0]: https://research.swtch.com/vgo-mvs https://research.swtch.com/vgo-mvs
      - 5y ago

codesections 5y ago

> I'll rather use a really small, static (as in never changing) package [instead of one] that get updates every day and breaking changes from time to time. That's an entirely fair point and, as I got into a bit in the versioning[0] section, something that I'm giving a good deal of thought too. I'm currently leaning towards tracking the Rakudo[1] compiler releases (~monthly), so updates wouldn't be anything like daily. As far *breaking* changes go – well, again, I'm still thinking about/discussing what guarantees to make, but I'm hoping to be able to promise to (try to) provide strong backwards compatibility. One thing I mentioned in the post is that Raku's strong support for multiple dispatch[2] makes backwards compatibility a bit easier: `_` can add a new version of a function without impacting the existing one. That still leaves _accidental_ breakage (i.e., bugs) – which is the area I'm currently most concerned about. If not handled correctly, a utility package risks creating its own sort of internal dependency hell: if there's a bug in one sub-package that you use, it could potentially block you from using that version – even if a different sub-package has a feature you want. I'm not sure of the best solution yet, but I'm exploring a few Raku options that I think may let me provide versions at the sub-package level (or maybe even the function level?). That's very much a WIP for now, but it's something that'll happen before a 1.0.0 release. [0]: https://raku-advent.blog/2021/12/11/unix_philosophy_without_leftpad_part2/#versioning https://raku-advent.blog/2021/12/11/unix_philosophy_without_... [1]: https://rakudo.org/ https://rakudo.org/

masklinn 5y ago

> The problem was that NPM changed ownership of already existing package-names - which caused the left-pad owner to remove his packages in protest. And of course that npm allowed unilaterally pulling packages and breaking all dependents.

HPsquared 5y ago

In this vein, for particularly sensitive applications (e.g. password managers) I prefer to disable automatic updates.

jasonpeacock 5y ago
How do you identify when to perform updates for security reasons?
- wincent 5y ago
  I think poster is saying turn _off_ "Automatically install updates" but leave _on_ "Check for updates [Daily/Weekly/Monthly]". That way you at least become aware that updates are available, and can assess them for yourself.

eternityforest 5y ago

Those large libraries don't change either, if you use a fixed version. Security updates are important, but it's not like CVEs are particularly common in 5 functions like left-pad, and bloated code that isn't reachable in your app is probably not going to be an attack surface. Especially if a dead code remover gets it.

dundarious 5y ago
JDNI was "dead code" for almost everybody, in that nobody intentionally used or wanted it. Unfortunately it was really just "dormant code" waiting to wake up. There is a dial from small to large (in terms of code size or feature set), static or growing feature set, pinned to floating dependencies (if you are notified on available updates to your pinned version and review them, which is actually possible for small dependencies, it's largely equivalent to floating). I don't think anyone is going to be able to convincingly say "my choice of large, growing, floating is best", or even though it's my starting preference, convincingly say "small, static, pinned is best". If you don't have the features or performance you need yet, you can make a good choice in picking a growing, floating dependency -- your call. But there is absolutely in my mind a need for greater general discipline in dependency capabilities. We don't need a monad stack or effects system in order to say "you can't add code to remote download, deserialize, and execute, in a call to log, that's just not a sensible thing to do". Or maybe we do, because much of us still haven't learned this lesson.
- b3morales 5y ago
  It doesn't apply universally, but in front end development a large part of the problem is that engineering is not, in practice, the ultimate decider for (all) dependencies. The business/product side often dictates integration with a particular third-party service; those services don't have an option to not use their own SDK, and the SDK itself may come with its own dependencies. To the business side, security risk looks abstract, theoretical, and easy to "it can't happen to me", especially compared to whatever goal is tied to the integration. Facebook in mobile applications is a perfect example. Not a security issue, but the two crash incidents last year caused some havoc for iOS developers. But as far as I am aware the only way to get Facebook login in your mobile app is to use the SDK, and no product manager on the planet is going to let engineering talk them out of Facebook user support.