4 ms·

I'm going to use this as an opportunity to vent. Wouldn't it be a nice world where you can just declare something EOL and it disappears and somehow magically i

I'm going to use this as an opportunity to vent. Wouldn't it be a nice world where you can just declare something EOL and it disappears and somehow magically it's not a problem anymore for anyone end-to-end? Thing's just don't work that way. Like, suddenly, a product that was working perfectly fine for who knows how long suddenly needs to modified because some ass-hats thinks that EOL isn't suitable for production. There are a number of reasons to upgrade a dependency or a product; an EOL label shouldn't be a part of the calculus. EOL may imply certain conditions that may influence the decision to upgrade but for the sake of EOL you can eat a bag of dicks. Think harder why you're proposing an upgrade is needed and how it'll add value to the business. EOL software is perfectly fine especially because it's been battle tested. We also use log4j 1.x all over the place and I feel zero need to change that.

dimitrios1 5y ago
It is perfectly reasonable to continue to use EOL software, but you have to assume maintenance costs in that case. It would be irresponsible to continue to use EOL software as is. EOL is a perfectly natural concept. Nothing in this world lasts forever, including our machines, electronics, cars, batteries, lives, and yes, software.
- rkagerer 5y ago
  If software lasted a lifetime, life would be so much easier.
  - kortex 5y ago
    For the end user, not the maintainers. Who's gonna sign up to keep that ENIAC, PDP-11, ALGOL 58, python2.3, win3.1, etc, code running, stable, and not a source of exploits? Or do you mean in the abstract, fairy-tale ending sense?
    - dimitrios1 5y ago
      I think they meant in the tongue-in-cheek sense.
Dylan16807 5y ago
> EOL may imply certain conditions And "EOL" is a convenient shorthand for those conditions. Most use cases care about never getting patches for security problems ever again.
Shared404 5y ago
> We also use log4j 1.x all over the place and I feel zero need to change that. I dunno, a widly known RCE seems a pretty good reason to take something out of production.
- fiddlerwoaroof 5y ago
  This is a case of “too old to be vulnerable”: the exploit only affects log4j 2.x
  - Shared404 5y ago
    Ah makes sense. I should've looked it up and double checked before commenting, my bad. Honestly, in that case I tend to agree with GP. As long as you recognize EOL means you are in charge of supporting it and possibly backporting security fixes and you're okay with that - why not use it?
    - smaudet 5y ago
      I agree EOL is too often interpreted to mean 'Insecure' - in the case of closed solutions this is absolutely the case (presumably, it is often difficult to audit closed and obfuscated closed source solutions). In many cases it is not, it is purely a 'ticking time bomb' - if new CVEs or requirements arise which cause issues in EOL versions, you may not even become aware of the vuln. In counterbalance, new versions of code have new, unknown CVEs, new bugs, etc. The issue is that of support, the fallacy and process issue is that 'current' support is of greater quality than 'historical' support, or that old software has a disproportionately higher support costs than 'current' software. The true issue is overdependence on FOSS software and unwillingess to contribute - all software has costs, major vendors are 'coasting' on work provided by free volunteers and panic when those volunteers decide to no longer work for free. If vendors were doing the legwork necessary to properly inhouse their dependencies, I would wager that much less software would end up discarded in 'fear', for a lack of a better word than this - modern development is supposedly built on features and patches, any codebase should be maintainable for a much longer period than its supposed EOL.
GoblinSlayer 5y ago
I don't see a problem, customer/employer pays and modifications happen.
andrewjl 5y ago
> There are a number of reasons to upgrade a dependency or a product; an EOL label shouldn't be a part of the calculus. If the end user of the product or their needs don't matter, sure.

dimitrios1 5y ago

It is perfectly reasonable to continue to use EOL software, but you have to assume maintenance costs in that case. It would be irresponsible to continue to use EOL software as is. EOL is a perfectly natural concept. Nothing in this world lasts forever, including our machines, electronics, cars, batteries, lives, and yes, software.

rkagerer 5y ago
If software lasted a lifetime, life would be so much easier.
- kortex 5y ago
  For the end user, not the maintainers. Who's gonna sign up to keep that ENIAC, PDP-11, ALGOL 58, python2.3, win3.1, etc, code running, stable, and not a source of exploits? Or do you mean in the abstract, fairy-tale ending sense?
  - dimitrios1 5y ago
    I think they meant in the tongue-in-cheek sense.

Dylan16807 5y ago

> EOL may imply certain conditions And "EOL" is a convenient shorthand for those conditions. Most use cases care about never getting patches for security problems ever again.

Shared404 5y ago

> We also use log4j 1.x all over the place and I feel zero need to change that. I dunno, a widly known RCE seems a pretty good reason to take something out of production.

fiddlerwoaroof 5y ago
This is a case of “too old to be vulnerable”: the exploit only affects log4j 2.x
- Shared404 5y ago
  Ah makes sense. I should've looked it up and double checked before commenting, my bad. Honestly, in that case I tend to agree with GP. As long as you recognize EOL means you are in charge of supporting it and possibly backporting security fixes and you're okay with that - why not use it?
  - smaudet 5y ago
    I agree EOL is too often interpreted to mean 'Insecure' - in the case of closed solutions this is absolutely the case (presumably, it is often difficult to audit closed and obfuscated closed source solutions). In many cases it is not, it is purely a 'ticking time bomb' - if new CVEs or requirements arise which cause issues in EOL versions, you may not even become aware of the vuln. In counterbalance, new versions of code have new, unknown CVEs, new bugs, etc. The issue is that of support, the fallacy and process issue is that 'current' support is of greater quality than 'historical' support, or that old software has a disproportionately higher support costs than 'current' software. The true issue is overdependence on FOSS software and unwillingess to contribute - all software has costs, major vendors are 'coasting' on work provided by free volunteers and panic when those volunteers decide to no longer work for free. If vendors were doing the legwork necessary to properly inhouse their dependencies, I would wager that much less software would end up discarded in 'fear', for a lack of a better word than this - modern development is supposedly built on features and patches, any codebase should be maintainable for a much longer period than its supposed EOL.

GoblinSlayer 5y ago

I don't see a problem, customer/employer pays and modifications happen.

andrewjl 5y ago

> There are a number of reasons to upgrade a dependency or a product; an EOL label shouldn't be a part of the calculus. If the end user of the product or their needs don't matter, sure.