3 ms·

Alternatively, if you rely on some code then download a specific version and check it before using it. Report any problems found. This makes usage robust and s

Alternatively, if you rely on some code then download a specific version and check it before using it. Report any problems found. This makes usage robust and supports open source support and development.

SV_BubbleTime 2y ago
I guess that would work if new exploits weren’t created or discovered. Otherwise all your plan to “run old software” is questionable.
- m0llusk 2y ago
  That isn't the plan. For this to work new versions have to be aggressively adopted. This is about accepting that using an open source project means adopting that code. If you had an internal library with bug fixes available then the right thing is to review those fixes and merge them into the development stream. It is the same with open source code you are using. If you care to continue using it then you need to get the latest and review code changes. This is not using old code, this is taking the steps needed to continue using code.
j1elo 2y ago
Vendoring should be the norm, not the special case. Something like this ought to be an essential part of all package managers, and I'm thinking here that the first ones should be the thousands of devs cluelessly using NPM around the world: https://go.dev/ref/mod#vendoring https://go.dev/ref/mod#vendoring
- bryanlarsen 2y ago
  We've seen a lot more attacks succeed because somebody has vendored an old vulnerable library than supply chain attacks. Doing vendoring badly is worse than relying on upstream. Vendoring is part of the solution, but it isn't the solution by itself.
  - j1elo 2y ago
    Not alone, no. That's how CI bots help a lot, such as Dependabot. Althought it's also worrying how we seemingly need more technologies on top of technologies just to keep a project alive. It used to be just including the system's patched header & libs, now we need extra bots surveying everything... Maybe a linux-distro-style of community dependency management would make sense. Keep a small group of maintainers busy with security patches for basically everything, and as a downstream developer just install the versions they produce. I can visualize the artwork..."Debian but for JS"
    - skydhash 2y ago
      In the old ways, you mostly rely on a few libraries that each solve a complete problem and is backed by a proper community. The odd dependency is usually small and vendored properly. Security was mostly the environment concern (the OS) as the data is either client side or some properly managed enterprise infrastructure). Now we have npm with its microscopic and numerous packages, everyone wants to be on the web, and they all want your data.
program_whiz 2y ago
I'm afraid this is hitting on the other end of inviolable game theory laws. Dev who is paid for features and business value wants to read line-by-line random package that is upgrading from version 0.3.12 to 0.3.13 in a cryptography or date lib that they likely don't understand? And this should be done for every change of every library for all software, by all devs who will always be responsible, not lazy, and very attentive and careful. On the flip side there is "doing as little as possible and getting paid" for the remainder of a 40 year career where you are likely to be shuffled off when the company has a bad quarter anyway. In my opinion, if that was incentivized by our system, we'd already be seeing more of it, we have the system we have due to the incentives we have.
- ravenstine 2y ago
  Correct. I don't think I have ever seen sound engimeering decisions being rewarded at any business I have worked for. The only reason any sound decisions are made is that some programmers take the initiative, but said initiative rarely comes with a payoff and always means fighting with other programmers who have a fetish for complexity. If only programmers had to take an ethics oath so they have an excuse not to just go along with idiotic practices.
  - PaulHoule 2y ago
    Then there are the programmers who read on proggit that “OO drools, functional programming rules” or the C++ programmers who think having a 40 minute build proves how smart and tough they are, etc.
  - ricardobayes 2y ago
    "Fetish for complexity" haha. This sounds so much better than "problem engineer".
  - BandButcher 2y ago
    lmao you jogged a memory in my brain... in my senior final semester in college, our professor had us agree to the IEEE Code of Ethics: https://www.computer.org/education/code-of-ethics https://www.computer.org/education/code-of-ethics In retrospect I can say I've held up for the most part, but in some cases have had to quit certain jobs due to overwhelming and accelerating nonsense. usually its best for your mental well to just shut up and get paid ;)
mnau 2y ago
> Report any problems found. This makes usage robust and supports open source support and development. Project maintainers/developers are not free labor. If you need a proper solution to any problem, make a contract and pay them. This idea that someone will magically solve your problem for free needs to die. https://www.softwaremaxims.com/blog/not-a-supplier https://www.softwaremaxims.com/blog/not-a-supplier

SV_BubbleTime 2y ago

I guess that would work if new exploits weren’t created or discovered. Otherwise all your plan to “run old software” is questionable.

m0llusk 2y ago
That isn't the plan. For this to work new versions have to be aggressively adopted. This is about accepting that using an open source project means adopting that code. If you had an internal library with bug fixes available then the right thing is to review those fixes and merge them into the development stream. It is the same with open source code you are using. If you care to continue using it then you need to get the latest and review code changes. This is not using old code, this is taking the steps needed to continue using code.

j1elo 2y ago

Vendoring should be the norm, not the special case. Something like this ought to be an essential part of all package managers, and I'm thinking here that the first ones should be the thousands of devs cluelessly using NPM around the world: https://go.dev/ref/mod#vendoring https://go.dev/ref/mod#vendoring

bryanlarsen 2y ago
We've seen a lot more attacks succeed because somebody has vendored an old vulnerable library than supply chain attacks. Doing vendoring badly is worse than relying on upstream. Vendoring is part of the solution, but it isn't the solution by itself.
- j1elo 2y ago
  Not alone, no. That's how CI bots help a lot, such as Dependabot. Althought it's also worrying how we seemingly need more technologies on top of technologies just to keep a project alive. It used to be just including the system's patched header & libs, now we need extra bots surveying everything... Maybe a linux-distro-style of community dependency management would make sense. Keep a small group of maintainers busy with security patches for basically everything, and as a downstream developer just install the versions they produce. I can visualize the artwork..."Debian but for JS"
  - skydhash 2y ago
    In the old ways, you mostly rely on a few libraries that each solve a complete problem and is backed by a proper community. The odd dependency is usually small and vendored properly. Security was mostly the environment concern (the OS) as the data is either client side or some properly managed enterprise infrastructure). Now we have npm with its microscopic and numerous packages, everyone wants to be on the web, and they all want your data.

program_whiz 2y ago

I'm afraid this is hitting on the other end of inviolable game theory laws. Dev who is paid for features and business value wants to read line-by-line random package that is upgrading from version 0.3.12 to 0.3.13 in a cryptography or date lib that they likely don't understand? And this should be done for every change of every library for all software, by all devs who will always be responsible, not lazy, and very attentive and careful. On the flip side there is "doing as little as possible and getting paid" for the remainder of a 40 year career where you are likely to be shuffled off when the company has a bad quarter anyway. In my opinion, if that was incentivized by our system, we'd already be seeing more of it, we have the system we have due to the incentives we have.

ravenstine 2y ago
Correct. I don't think I have ever seen sound engimeering decisions being rewarded at any business I have worked for. The only reason any sound decisions are made is that some programmers take the initiative, but said initiative rarely comes with a payoff and always means fighting with other programmers who have a fetish for complexity. If only programmers had to take an ethics oath so they have an excuse not to just go along with idiotic practices.
- PaulHoule 2y ago
  Then there are the programmers who read on proggit that “OO drools, functional programming rules” or the C++ programmers who think having a 40 minute build proves how smart and tough they are, etc.
- ricardobayes 2y ago
  "Fetish for complexity" haha. This sounds so much better than "problem engineer".
- BandButcher 2y ago
  lmao you jogged a memory in my brain... in my senior final semester in college, our professor had us agree to the IEEE Code of Ethics: https://www.computer.org/education/code-of-ethics https://www.computer.org/education/code-of-ethics In retrospect I can say I've held up for the most part, but in some cases have had to quit certain jobs due to overwhelming and accelerating nonsense. usually its best for your mental well to just shut up and get paid ;)

mnau 2y ago

> Report any problems found. This makes usage robust and supports open source support and development. Project maintainers/developers are not free labor. If you need a proper solution to any problem, make a contract and pay them. This idea that someone will magically solve your problem for free needs to die. https://www.softwaremaxims.com/blog/not-a-supplier https://www.softwaremaxims.com/blog/not-a-supplier