4 ms·

Until all hundreds of thousands of projects have changed that, it'll take time. That doesn't mention the fact you now also have to fork unmaintained projects r

by zaarn 5y ago

Until all hundreds of thousands of projects have changed that, it'll take time. That doesn't mention the fact you now also have to fork unmaintained projects relying on log4j to use the new version. If you're developing a major java projects, that's potentially thousands of dependencies you have to patch. I'm not suggesting that closed source is the solution, I'm saying the current system is not sustainable and neither is just forking projects. Because which fork do you follow, and how do you make sure all your dependencies follow the fork you want and not an unmaintained fork?

the_duke 5y ago
Some package managers (eg yarn , cargo) have a solution for that and allow you to specify a local resolution override that will apply to all dependencies.
- zaarn 5y ago
  But again, that means EVERY single product, open source or not, will have to patch their deployment to use the fork instead of simply using the updated version of upstream. Permanently no less if it's unmaintained. Meaning every single Java product would have to include that "if you want to use log4j, you have to include this patch line to use a fork, because of unmaintained dependencies". That just ossifies log4j and fixes nothing. Patching dependencies in Cargo is not meant to permanently replace code, it's to be used while you're waiting for an upstream merge.
  - IiydAbITMvJkqKf 5y ago
    You can fix it for your own applications and libraries. The tooling exists. You can't force other people to use your fork.
    - zaarn 5y ago
      Correct, all those other people will have to manually find some fork or make their own, repeating the same work thousands of times and ossifying that some part of your java build system now permanently includes a section to patch log4j dependencies.
      - alexvoda 5y ago
        You can not force your dependencies to do what you want. You can only patch the problem for yourself and maintain that patch in the build system, or you can fork each dependency in the chain, maintain those and then your build system is cleaner. There is nothing wrong with these options.
        zaarn 5y ago
        Forking yourself is not scalable for fixing a 10/10CVE and I don't get how people think that somehow "fork it" is a viable solution across the entire industry. This is not about forcing my dependencies to do anything, this is about caring about maintainers and maybe ensuring that the bedrock of our ecosystems aren't maintained by unpaid volunteers in their free time, exploiting the sweat on their backs for our amusement for free. Forking the project is just spitting on their efforts on top of that.
        alexvoda 5y ago
        Entirely agree, we should find ways to reliably support upstream. But that is a different issue, and unfortunately it is one that the main beneficiaries are not willing to solve. Forking solves the issue of an upstream dependency not willing to fix a bug.
        zaarn 5y ago
        As I've pointed out a few times now, forking upstream is not a long term or sustainable solution.
  - kristjansson 5y ago
    Does it matter that other products don’t patch something that yours does? Like, sure, it’s unsatisfying from an ecosystem perspective, and one would hope for fixes to be incorporated upstream. But if they aren’t, who cares if other products are broken after you’ve patched the ones you’re responsible for?
    - zaarn 5y ago
      It does because now I pull in a dependency that indirectly relies on log4j instead of my favorite fork of log4j and I end up having the same CVE in the project anyway. Yes this needs to work ecosystem wide, otherwise you have fixed nothing at all.
      - the_af 5y ago
        > It does because now I pull in a dependency How would proprietary software make this better? You wouldn't even have anything to pull in! Is your argument "having the source code and the legal rights to fix this bug even when nobody else wants to or even can fix it is not good enough because not everyone will use my fix"? Because good luck with proprietary software then!
        zaarn 5y ago
        My argument is not closed source. My argument is that "just fork it" does not magically fix all problems. Closed source makes this worse but "fork it" is no answer either. I believe I made this very clear on my very first comment.
        kristjansson 5y ago
        Right … open source doesn’t guarantee an absence of problems, only that, in the worst case, a user can repair a problem herself. As you note, that’s strictly preferable to closed source, where a problem with a dependency is not guaranteed to be fixable by the user. Isn’t that enough?
- deleted 5y ago
  [deleted]

by zaarn 5y ago

the_duke 5y ago

Some package managers (eg yarn , cargo) have a solution for that and allow you to specify a local resolution override that will apply to all dependencies.

zaarn 5y ago
But again, that means EVERY single product, open source or not, will have to patch their deployment to use the fork instead of simply using the updated version of upstream. Permanently no less if it's unmaintained. Meaning every single Java product would have to include that "if you want to use log4j, you have to include this patch line to use a fork, because of unmaintained dependencies". That just ossifies log4j and fixes nothing. Patching dependencies in Cargo is not meant to permanently replace code, it's to be used while you're waiting for an upstream merge.
- IiydAbITMvJkqKf 5y ago
  You can fix it for your own applications and libraries. The tooling exists. You can't force other people to use your fork.
  - zaarn 5y ago
    Correct, all those other people will have to manually find some fork or make their own, repeating the same work thousands of times and ossifying that some part of your java build system now permanently includes a section to patch log4j dependencies.
    - alexvoda 5y ago
      You can not force your dependencies to do what you want. You can only patch the problem for yourself and maintain that patch in the build system, or you can fork each dependency in the chain, maintain those and then your build system is cleaner. There is nothing wrong with these options.
      - zaarn 5y ago
        Forking yourself is not scalable for fixing a 10/10CVE and I don't get how people think that somehow "fork it" is a viable solution across the entire industry. This is not about forcing my dependencies to do anything, this is about caring about maintainers and maybe ensuring that the bedrock of our ecosystems aren't maintained by unpaid volunteers in their free time, exploiting the sweat on their backs for our amusement for free. Forking the project is just spitting on their efforts on top of that.
        alexvoda 5y ago
        Entirely agree, we should find ways to reliably support upstream. But that is a different issue, and unfortunately it is one that the main beneficiaries are not willing to solve. Forking solves the issue of an upstream dependency not willing to fix a bug.
        zaarn 5y ago
        As I've pointed out a few times now, forking upstream is not a long term or sustainable solution.
- kristjansson 5y ago
  Does it matter that other products don’t patch something that yours does? Like, sure, it’s unsatisfying from an ecosystem perspective, and one would hope for fixes to be incorporated upstream. But if they aren’t, who cares if other products are broken after you’ve patched the ones you’re responsible for?
  - zaarn 5y ago
    It does because now I pull in a dependency that indirectly relies on log4j instead of my favorite fork of log4j and I end up having the same CVE in the project anyway. Yes this needs to work ecosystem wide, otherwise you have fixed nothing at all.
    - the_af 5y ago
      > It does because now I pull in a dependency How would proprietary software make this better? You wouldn't even have anything to pull in! Is your argument "having the source code and the legal rights to fix this bug even when nobody else wants to or even can fix it is not good enough because not everyone will use my fix"? Because good luck with proprietary software then!
      - zaarn 5y ago
        My argument is not closed source. My argument is that "just fork it" does not magically fix all problems. Closed source makes this worse but "fork it" is no answer either. I believe I made this very clear on my very first comment.
        kristjansson 5y ago
        Right … open source doesn’t guarantee an absence of problems, only that, in the worst case, a user can repair a problem herself. As you note, that’s strictly preferable to closed source, where a problem with a dependency is not guaranteed to be fixable by the user. Isn’t that enough?
deleted 5y ago
[deleted]