6 ms·

> I don't want that level of control over other people's projects, it's scary How far do you take this though? The average GNU Linux distro ships with a whole

> I don't want that level of control over other people's projects, it's scary How far do you take this though? The average GNU Linux distro ships with a whole pile of packages already installed, from a multitude of different authors.

rajin444 5y ago
There’s no reason people can’t keep local caches of these libs if it is a major concern. This seems like a non issue.
- MaxBarraclough 5y ago
  Stale libraries are more likely to contain known security vulnerabilities.
  - temp12192021 5y ago
    I know it's bad practice, but I just checkin vendor files/libs to source control. Makes auditing new releases of libraries a bit easier. Assuming they aren't binaries of course.
    - cerved 5y ago
      I don't recommend this approach
      - temp12192021 5y ago
        I haven't had issues yet, but it's considered bad practice for a reason. What headaches am I in store for?
        cerved 5y ago
        You're committing something that is not a part of your source code into your version control system, assuming your source code is git, this is irrevocable without rewriting history. It's mainly a nuisance. It takes up unnecessary space. Introduces possible annoying merge conflicts etc etc and it's not trivial to remove it. As reference, I migrated repositories from TFVC to git. One team relies on checking in packages into source control, another one does so far less. One repo is significantly nimbler. Checking packages into source control is making your VCS a package manager. Presumably you have one. Don't hammer nails with your screwdriver
        charcircuit 5y ago
        The benefit of having your dependencies vendored is that you have everything needed to build your application without having to download stuff from the internet. You get to ensure what exactly makes it into your application. Yes, it will increase the repository size, but I don't see why merge conflicts would be a problem since you are just replacing a file with a new version.
        arvinsim 5y ago
        I imagine your commit log would be polluted with commits just for changes in the packages.
        charcircuit 5y ago
        You would have one anyways for changing the lock file or whatever. Changing your dependencies is something that you may want to be able to undo. It's useful to be able to go back to a known working version of your program with versions of your dependencies that you know work.
        deleted 5y ago
        [deleted]
        cerved 5y ago
        > you have everything needed to build your application without having to download stuff from the internet that's using version control to act as a proxy. AFAIK, a lot of package managers already cache local copies > You get to ensure what exactly makes it into your application sorry but i don't follow > I don't see why merge conflicts would be a problem since you are just replacing a file with a new version Are you working alone?
        tobyhinloopen 5y ago
        I’ve been doing it witb Yarn 2 / pnp and it has been great so far. You checkout a project and start it. No downloading required, and no 10000s of files.
    - jay_kyburz 5y ago
      I also like doing this, but with node, you have a massive tree of thousands of files. It's crazy and gross.
      - tobyhinloopen 5y ago
        Yarn 2 pnp kinda fixes this
  - rajin444 5y ago
    You’re free to update as you like. It’s entirely possible to audit your local packages. Letting maintainers update your projects is a convenient feature. If it is a liability in your use case you can work around it. Yes it will take more effort, but your use case justifies it.
notRobot 5y ago
Yes, but AFAIK, those are heavily tested or audited in some manner. That's different from including code written by randos in your app that they can remotely change at any time.
- rich_sasha 5y ago
  In practical terms, can they really be audited? This is at least obvious DoS, I’m sure it’s easy to slip in an innocuous line that, dunno, ships your ssh keys to some rando server.
  - cerved 5y ago
    look at diffs?
    - apetresc 5y ago
      Can you really say, with a straight face, that you inspect the diffs of your entire dependency closure every time you deploy an update? With the level of scrutiny required to detect a maliciously-obfuscated security exploit? If you can, you're an infinitely more diligent developer than I am, that's for sure.
      - dane-pgp 5y ago
        Fortunately the problem could become more tractable if something like SES / Endo takes off: "Endo protects program integrity both in-process and in distributed systems. SES protects local integrity, defending an application against supply chain attacks: hacks that enter through upgrades to third-party dependencies. Endo does this by encouraging the Principle of Least Authority. ... Endo uses LavaMoat to automatically generate reviewable policies that determine what capabilities will be distributed to third party dependencies." https://github.com/endojs/endo https://github.com/endojs/endo
        naasking 5y ago
        Nice link, thanks! Good to see Mark Miller is still working in this space.
bee_rider 5y ago
Packing is most of the point of a distro. They are specifically taking on that responsibility. They also have a better perspective to handle overall compatibility. In a sense you've pointed out the alternative to having the programmer handling the packaging -- having some third party package and distribute. And this separation of responsibility turns out be almost always be a better solution. Distribution and coding are, after all, two full jobs (without 100% skill overlap). Plus, hopefully it indicates that at least two sets of eyeballs have at least glanced at the code (not the full desired many-eyeball outcome, but as good as we can expect sometimes).
- mschuster91 5y ago
  Given that Debian (and its descendants...) packages a shitload of npm packages, it's a wide stretch to say there is more QA for these packages from the Debian side than there is from the npm side. The one thing that Debian provides is that in the case there is a security issue, admins worldwide only need to do "apt update && apt upgrade" and they are safe, without having to check all of the software that runs on their servers (as long as said software comes from Debian, that is!).
  - bee_rider 5y ago
    I do think people would be served, generally, by being more aware of the fact that distros are not some doing some hardcore security vetting. But the alternative is just to use whatever was pushed up to NPM, right? In that case, Debian packager+NPM push > NPM push by definition, unless the Debian packager somehow provides negative QA, which seems unlikely. (Also, on the incredibly unlikely offchance that some Debian packager reads this comment -- your work is incredibly useful and I very much appreciate it, just trying to be realistic about what exactly is provided by your group!)
    - _-david-_ 5y ago
      > unless the Debian packager somehow provides negative QA, which seems unlikely It has happened before. Last time there was anything major was over a decade ago though. https://lists.debian.org/debian-security-announce/2008/msg00152.html https://lists.debian.org/debian-security-announce/2008/msg00...

rajin444 5y ago

There’s no reason people can’t keep local caches of these libs if it is a major concern. This seems like a non issue.

MaxBarraclough 5y ago
Stale libraries are more likely to contain known security vulnerabilities.
- temp12192021 5y ago
  I know it's bad practice, but I just checkin vendor files/libs to source control. Makes auditing new releases of libraries a bit easier. Assuming they aren't binaries of course.
  - cerved 5y ago
    I don't recommend this approach
    - temp12192021 5y ago
      I haven't had issues yet, but it's considered bad practice for a reason. What headaches am I in store for?
      - cerved 5y ago
        You're committing something that is not a part of your source code into your version control system, assuming your source code is git, this is irrevocable without rewriting history. It's mainly a nuisance. It takes up unnecessary space. Introduces possible annoying merge conflicts etc etc and it's not trivial to remove it. As reference, I migrated repositories from TFVC to git. One team relies on checking in packages into source control, another one does so far less. One repo is significantly nimbler. Checking packages into source control is making your VCS a package manager. Presumably you have one. Don't hammer nails with your screwdriver
        charcircuit 5y ago
        The benefit of having your dependencies vendored is that you have everything needed to build your application without having to download stuff from the internet. You get to ensure what exactly makes it into your application. Yes, it will increase the repository size, but I don't see why merge conflicts would be a problem since you are just replacing a file with a new version.
        arvinsim 5y ago
        I imagine your commit log would be polluted with commits just for changes in the packages.
        charcircuit 5y ago
        You would have one anyways for changing the lock file or whatever. Changing your dependencies is something that you may want to be able to undo. It's useful to be able to go back to a known working version of your program with versions of your dependencies that you know work.
        deleted 5y ago
        [deleted]
        cerved 5y ago
        > you have everything needed to build your application without having to download stuff from the internet that's using version control to act as a proxy. AFAIK, a lot of package managers already cache local copies > You get to ensure what exactly makes it into your application sorry but i don't follow > I don't see why merge conflicts would be a problem since you are just replacing a file with a new version Are you working alone?
      - tobyhinloopen 5y ago
        I’ve been doing it witb Yarn 2 / pnp and it has been great so far. You checkout a project and start it. No downloading required, and no 10000s of files.
  - jay_kyburz 5y ago
    I also like doing this, but with node, you have a massive tree of thousands of files. It's crazy and gross.
    - tobyhinloopen 5y ago
      Yarn 2 pnp kinda fixes this
- rajin444 5y ago
  You’re free to update as you like. It’s entirely possible to audit your local packages. Letting maintainers update your projects is a convenient feature. If it is a liability in your use case you can work around it. Yes it will take more effort, but your use case justifies it.

notRobot 5y ago

Yes, but AFAIK, those are heavily tested or audited in some manner. That's different from including code written by randos in your app that they can remotely change at any time.

rich_sasha 5y ago
In practical terms, can they really be audited? This is at least obvious DoS, I’m sure it’s easy to slip in an innocuous line that, dunno, ships your ssh keys to some rando server.
- cerved 5y ago
  look at diffs?
  - apetresc 5y ago
    Can you really say, with a straight face, that you inspect the diffs of your entire dependency closure every time you deploy an update? With the level of scrutiny required to detect a maliciously-obfuscated security exploit? If you can, you're an infinitely more diligent developer than I am, that's for sure.
    - dane-pgp 5y ago
      Fortunately the problem could become more tractable if something like SES / Endo takes off: "Endo protects program integrity both in-process and in distributed systems. SES protects local integrity, defending an application against supply chain attacks: hacks that enter through upgrades to third-party dependencies. Endo does this by encouraging the Principle of Least Authority. ... Endo uses LavaMoat to automatically generate reviewable policies that determine what capabilities will be distributed to third party dependencies." https://github.com/endojs/endo https://github.com/endojs/endo
      - naasking 5y ago
        Nice link, thanks! Good to see Mark Miller is still working in this space.

bee_rider 5y ago

Packing is most of the point of a distro. They are specifically taking on that responsibility. They also have a better perspective to handle overall compatibility. In a sense you've pointed out the alternative to having the programmer handling the packaging -- having some third party package and distribute. And this separation of responsibility turns out be almost always be a better solution. Distribution and coding are, after all, two full jobs (without 100% skill overlap). Plus, hopefully it indicates that at least two sets of eyeballs have at least glanced at the code (not the full desired many-eyeball outcome, but as good as we can expect sometimes).

mschuster91 5y ago
Given that Debian (and its descendants...) packages a shitload of npm packages, it's a wide stretch to say there is more QA for these packages from the Debian side than there is from the npm side. The one thing that Debian provides is that in the case there is a security issue, admins worldwide only need to do "apt update && apt upgrade" and they are safe, without having to check all of the software that runs on their servers (as long as said software comes from Debian, that is!).
- bee_rider 5y ago
  I do think people would be served, generally, by being more aware of the fact that distros are not some doing some hardcore security vetting. But the alternative is just to use whatever was pushed up to NPM, right? In that case, Debian packager+NPM push > NPM push by definition, unless the Debian packager somehow provides negative QA, which seems unlikely. (Also, on the incredibly unlikely offchance that some Debian packager reads this comment -- your work is incredibly useful and I very much appreciate it, just trying to be realistic about what exactly is provided by your group!)
  - _-david-_ 5y ago
    > unless the Debian packager somehow provides negative QA, which seems unlikely It has happened before. Last time there was anything major was over a decade ago though. https://lists.debian.org/debian-security-announce/2008/msg00152.html https://lists.debian.org/debian-security-announce/2008/msg00...