5 ms·

Imagine if we had a system where you could just deposit the source code for a program you work on into a "depository". You could set it up so your team could "

by cxr 1y ago

Imagine if we had a system where you could just deposit the source code for a program you work on into a "depository". You could set it up so your team could "admit" the changes that have your approval, but it doesn't allow third parties to modify what's in your depository (even if it's a library that you're using that they wrote). When you build/deploy your program, you only compile/run third-party versions that have been admitted to the depository, and you never just eagerly fetch other versions that purport to be updates right before build time. If there is an update, you can download a copy and admit it to your repo at the normal time that you verify that your program actually needs the update. Even if it sounds far-fetched, I imagine we could get by with a system like this.

edoceo 1y ago
That is exactly what I do.
anthk 1y ago
You are describing BSD ports from the 90's. FreeBSD ports date back to 1993.
- ok123456 1y ago
  Also, Gentoo dating back to 2003.
- SoftTalker 1y ago
  And today.
chrisweekly 1y ago
You're describing a custom registry. These exist IRL (eg jFrog Artifactory). Useful for managing allow-listed packages which have met whatever criteria you might have (eg CVE-free based on your security tool of choice). Use of a custom registry, and a sane package manager (pnpm, not npm), and its lockfile, will significantly enhance your supply-chain security.
- cxr 1y ago
  No. I am literally describing bog standard use of an ordinary VCS/SCM where the code for e.g. Skia, sqlite, libpng, etc. is placed in a "third-party/" subdirectory. Except I'm deliberately using the words "admit" and "depository" here instead of "commit" and "repository" in keeping with the theme—of the widespread failure of people to use SCMs to manage the corresponding source code required to build their product/project. Overlay version control systems like NPM, Cargo, etc. and their harebrained schemes involving "lockfiles" to paper over their deficiencies have evidently totally destroyed not just folks' ability to conceive of just using an SCM like Git or Mercurial to manage source the way that they're made for without introducing a second, half-assed, "registry"-dependent VCS into the mix, but also destroyed the ability to recognize when a comment on the subject is dripping in the most obvious, easily detectable irony.
  - morshu9001 1y ago
    Does the lockfile not solve this?
    - cxr 1y ago
      What is "this"?
      - morshu9001 1y ago
        this = deps getting updated when you don't want or don't expect them to
        cxr 1y ago
        We do not appear to have a shared understanding of the problem to be solved. This is because you have redefined the problem—partly as a way of allowing you to avoid addressing it, and partly to allow you to speak of lockfiles as a solution to that problem. See <https://news.ycombinator.com/item?id=45824392 https://news.ycombinator.com/item?id=45824392>. Lockfiles do not solve the problem. They are the problem. This is what I wrote: > Overlay version control systems like NPM, Cargo, etc. and their harebrained schemes involving "lockfiles" to paper over their deficiencies have evidently totally destroyed […] folks' ability to conceive of just using an SCM like Git That's the problem that I'm talking about—lockfiles. Or, more specifically: the insistence on practicing a form of version control (i.e. this style of dependency management that the current crop of package managers tell people is the Right Way to do things) that leads to the use of lockfiles—for the sole purpose of papering over the issues that were only introduced by this kind of package manager—and for people to be totally unaware of the water they're swimming in under this arrangement. Everyone is familiar with the concept of "a solution in need of a problem". That's exactly what lockfiles are.
kej 1y ago
Now you have the opposite problem, where a vulnerability could be found in one of your dependencies but you don't get the fix until the next "normal time that you verify that your program actually needs the update".
- edoceo 1y ago
  If a security issue is found that creates the "normal time". That is, when a security issue is found, regardless of supply chain tooling one would update. That there is a little cache/mirror thing in the middle is of little consequence in that case. And for all other cases the blessed versions in your mirror are better even if not latest.
  - kej 1y ago
    This is how most software used to work before internet package managers, and it turns out that the same people who aren't good at checking their dependencies before automatically upgrading are also not good at constantly monitoring their dependencies for vulnerabilities.
lenkite 1y ago
Well in the Java world, Maven had custom repositories which did this for the last 20+ years.
zahlman 1y ago
So, vendoring?
- cxr 1y ago
  That's a bingo.

by cxr 1y ago

edoceo 1y ago

That is exactly what I do.

anthk 1y ago

You are describing BSD ports from the 90's. FreeBSD ports date back to 1993.

ok123456 1y ago
Also, Gentoo dating back to 2003.
SoftTalker 1y ago
And today.

chrisweekly 1y ago

You're describing a custom registry. These exist IRL (eg jFrog Artifactory). Useful for managing allow-listed packages which have met whatever criteria you might have (eg CVE-free based on your security tool of choice). Use of a custom registry, and a sane package manager (pnpm, not npm), and its lockfile, will significantly enhance your supply-chain security.

cxr 1y ago
No. I am literally describing bog standard use of an ordinary VCS/SCM where the code for e.g. Skia, sqlite, libpng, etc. is placed in a "third-party/" subdirectory. Except I'm deliberately using the words "admit" and "depository" here instead of "commit" and "repository" in keeping with the theme—of the widespread failure of people to use SCMs to manage the corresponding source code required to build their product/project. Overlay version control systems like NPM, Cargo, etc. and their harebrained schemes involving "lockfiles" to paper over their deficiencies have evidently totally destroyed not just folks' ability to conceive of just using an SCM like Git or Mercurial to manage source the way that they're made for without introducing a second, half-assed, "registry"-dependent VCS into the mix, but also destroyed the ability to recognize when a comment on the subject is dripping in the most obvious, easily detectable irony.
- morshu9001 1y ago
  Does the lockfile not solve this?
  - cxr 1y ago
    What is "this"?
    - morshu9001 1y ago
      this = deps getting updated when you don't want or don't expect them to
      - cxr 1y ago
        We do not appear to have a shared understanding of the problem to be solved. This is because you have redefined the problem—partly as a way of allowing you to avoid addressing it, and partly to allow you to speak of lockfiles as a solution to that problem. See <https://news.ycombinator.com/item?id=45824392 https://news.ycombinator.com/item?id=45824392>. Lockfiles do not solve the problem. They are the problem. This is what I wrote: > Overlay version control systems like NPM, Cargo, etc. and their harebrained schemes involving "lockfiles" to paper over their deficiencies have evidently totally destroyed […] folks' ability to conceive of just using an SCM like Git That's the problem that I'm talking about—lockfiles. Or, more specifically: the insistence on practicing a form of version control (i.e. this style of dependency management that the current crop of package managers tell people is the Right Way to do things) that leads to the use of lockfiles—for the sole purpose of papering over the issues that were only introduced by this kind of package manager—and for people to be totally unaware of the water they're swimming in under this arrangement. Everyone is familiar with the concept of "a solution in need of a problem". That's exactly what lockfiles are.

kej 1y ago

Now you have the opposite problem, where a vulnerability could be found in one of your dependencies but you don't get the fix until the next "normal time that you verify that your program actually needs the update".

edoceo 1y ago
If a security issue is found that creates the "normal time". That is, when a security issue is found, regardless of supply chain tooling one would update. That there is a little cache/mirror thing in the middle is of little consequence in that case. And for all other cases the blessed versions in your mirror are better even if not latest.
- kej 1y ago
  This is how most software used to work before internet package managers, and it turns out that the same people who aren't good at checking their dependencies before automatically upgrading are also not good at constantly monitoring their dependencies for vulnerabilities.

lenkite 1y ago

Well in the Java world, Maven had custom repositories which did this for the last 20+ years.

zahlman 1y ago

So, vendoring?

cxr 1y ago
That's a bingo.