Hey folks,
So as requested I've made a conservative fully binary compatible version of
all the build changes and security fixes, patches are on a new pull request
at
https://github.com/apache/log4j/pull/17
On Sat, Dec 18, 2021 at 7:30 PM Gary Gregory <garydgreg...@gmail.com> wrote:
> Again, you cannot break binary compatibility in a minor release. That's a
> show stopper.
>
Ok, if that's what you want....hope the new approach is acceptable on
review.
I will note most of log4j 1.2 was not nearly so strict (semantic versioning
not being a standard 'thing' back then), as you can also tell from the
plans to drop chainsaw from 1.2.18 and so on...but it does make sense as a
policy in 2021 I guess.
Depending on what the consensus approach eventually becomes, you could also
pick up from an earlier commit, for example taking all the build fixes but
writing your own java code changes.
> This discussion IMO should ONLY be about mitigation of CVEs and that means
> porting the idea of the fixes from 2.x to 1.x. This 1.x component is EOL. I
> say "idea" because the code bases for 1.x and 2.x are completely different.
>
As I wrote before I don't agree with this part of the strategy you propose.
I understand it in the abstract but I do not think it is realistic. 2.x has
a lot of network code that is a lot better and more modern than is in 1.x.
Trying to have solid network code in 1.x while having it also be binary
compatible is way too much work, and even if you manage to then test that
things are behavior-compatible at runtime...there'd then be a real risk of
unintended regressions there.
I think the mitigation strategy that's on the PR now is good enough(tm) to
help many people.
>From my side, I am now out of time to work on this for the next couple of
weeks. I may try and check my e-mail a bit next week, but no promises. I
hope this is in a good state so others in the community can pick things up
from there!
Meanwhile, take care, cheers,
Leo
