I might be able to look into doing a log4j2 patch if there was interest in
that. But, I don't want to spend a lot of time doing that if the community
has already decided on logback.
On Thu, Jan 20, 2022 at 4:27 AM Szalay-Bekő Máté
wrote:
> I think we are slowly converging toward the following co
I think we are slowly converging toward the following conclusion (at least
this is how I see it).
- We want to make either Log4j2 or Logback as the default log engine.
- We would provide some blogpost / documentation / how-to about how to
change the default log engine. (even as simple as described
Thanks for the quick review Chris.
I agree with the second part of your e-mail completely. I’m not sure either
that the community has given a thumbs-up for logback, but I wanted to finalize
my patch sooner, because I have other duties to take care of.
I feel like logback is generally acceptable
Thank you, Andor. I entered one more round of very minor feedback.
I'm not sure about the licensing changes. I responded on the PR with my
thoughts, but I'd appreciate a second set of eyes on the licensing in
particular.
After resolving that feedback, I'll be ready to +1 from a code perspective,
I’m done with all the changes that I wanted to include in the first logback
patch.
Most of Chris’ feedback has also been addressed as well as the licensing
changes.
We have binary distribution which includes the logback jar, so I added EPL v1.0
to LINCENSE.txt and mentioned Logback in the NOTICE.
I believe that the primary contributor to logback was highly skeptical that
the recent problems could possible affect logback. That isn't a good
attitude for security problems.
It isn't just a matter of patch rate. There is also the question of
community size. Is logback effectively a one-man show
While it has had recent activity, it is notable that logback only recently
became active again for patches to the stable 1.2 releases. After several
releases in early 2017, it did not have a stable release for over four
years between 31-Mar-2017 (v1.2.3) and 19-Jul-2021 (v1.2.4).
On Tue, Jan 18,
Yes. It looks like logback is still actively being developed. 1.2 had a
release in December. The 1.3 line is still alpha and has also seen recent
releases (interestingly, it requires at least Java 9 to build, but will run
on Java 8, which is similar to what I had recommended for ZK in a different
t
I agree with you completely and this is crucial for logback too, so
correct me if I'm wrong. Logback is current and actively maintained. Is
that correct?
Andor
On Tue, 2022-01-18 at 12:43 -0500, Christopher wrote:
> I do think these are more good reasons to adopt
> something that is current and
I'm not opposed to moving faster, but just to be clear, none of those CVEs
look like they affect ZK's use of log4j1.2 at all.
* The use of Chainsaw is optional for users. To avoid the vulnerability,
they can just not use it.
* The XML entities issue would require users to put vulnerable config fil
Il giorno mar 18 gen 2022 alle ore 18:09 Andor Molnar
ha scritto:
>
> Thanks for the feedback Enrico / Christopher.
>
> CVEs have been popping up recently for log4j1:
>
> - CVE-2022-23305 Log4j v1 - SQL injection in JDBC Appender
> - CVE-2022-23306 Log4j v1 - Ability to send local files to remote
Thanks for the feedback Enrico / Christopher.
CVEs have been popping up recently for log4j1:
- CVE-2022-23305 Log4j v1 - SQL injection in JDBC Appender
- CVE-2022-23306 Log4j v1 - Ability to send local files to remote locations via
XML entities in log4j.xml
- CVE-2022-23307 A deserialization fl
On Fri, Jan 14, 2022 at 1:24 AM Enrico Olivelli wrote:
> Il Gio 13 Gen 2022, 09:48 Andor Molnar ha scritto:
>
> > Providing sample configs for logging backends which we don’t actively
> > maintain. I don’t this is gonna work. Maybe log4j.properties is already
> > broken too in some parts, becaus
Il Gio 13 Gen 2022, 09:48 Andor Molnar ha scritto:
> Providing sample configs for logging backends which we don’t actively
> maintain. I don’t this is gonna work. Maybe log4j.properties is already
> broken too in some parts, because we don’t have test coverage / active user
> base for that. Sound
Providing sample configs for logging backends which we don’t actively maintain.
I don’t this is gonna work. Maybe log4j.properties is already broken too in
some parts, because we don’t have test coverage / active user base for that.
Sounds to me a waste of effort and error-prone practice.
Using
On Wed, Jan 12, 2022 at 10:48 AM Andor Molnar wrote:
>
> slf4j-simple
>
>
> Based on the documenation:
> "Simple implementation of Logger that sends all enabled log messages, for all
> defined loggers, to the console (System.err).”
> https://www.slf4j.org/api/org/slf4j/impl/SimpleLog
slf4j-simple
Based on the documenation:
"Simple implementation of Logger that sends all enabled log messages, for all
defined loggers, to the console (System.err).”
https://www.slf4j.org/api/org/slf4j/impl/SimpleLogger.html
I see the following problems with this approach and don’t k
Ouch…
JUL doesn’t have MDC support.
> On 2022. Jan 12., at 12:48, Andor Molnar wrote:
>
> Thanks Chris and Christopher for resolving the licensing issue.
>
> Christopher, sorry for “fiasco” it might have not been accurate to describe
> what happened to log4j2 recently. Respect to Apache for
Thanks Chris and Christopher for resolving the licensing issue.
Christopher, sorry for “fiasco” it might have not been accurate to describe
what happened to log4j2 recently. Respect to Apache for responding quickly and
I understand the reason that Ted mentioned why logback responded more
reluct
The licensing question is resolved. We can state our choice of EPL, and
include only the text of EPL.
Chris Nauroth
On Mon, Jan 10, 2022 at 1:05 PM Ted Dunning wrote:
>
> I would add one more point. Logback has roughly benevolent dictator
> governance, Log4j is Apache. During the recent kerfuf
I would add one more point. Logback has roughly benevolent dictator
governance, Log4j is Apache. During the recent kerfuffle, Apache responded
sooner because it only took one of n people to start responding. Logback's
response for quite some time was "that's an Apache problem" even though
they had
Sorry, I meant to link to it in my previous reply, but I got
distracted and forgot: I also created
https://issues.apache.org/jira/browse/LEGAL-594 for the same. I
commented on yours to indicate it is effectively a duplicate.
On Mon, Jan 10, 2022 at 1:36 PM Chris Nauroth wrote:
>
> Regarding the l
Regarding the license, I'm confident that there will be a path forward. I'm
just not confident in my understanding of requirements (if any) to record a
choice of EPL instead of LGPL. I decided to file an issue to Legal to get
clarity, and I'll keep this thread updated.
https://issues.apache.org/ji
On Mon, Jan 10, 2022 at 9:17 AM Andor Molnar wrote:
>
> Thanks for all the feedback and concerns folks. I’m trying organize them in
> bullet points. Order is random, not importance.
>
> 1) Licence. I’m not familiar with dual-licensing either. Maybe we need
> somebody with better Apache knowledge
Thanks Enrico.
Chris has -1 on the patch. I need to address his comments first and
unfortunately cannot promise this week.
A.
> On 2022. Jan 10., at 15:30, Enrico Olivelli wrote:
>
> Andor,
>
> Il giorno lun 10 gen 2022 alle ore 15:17 Andor Molnar
> ha scritto:
>>
>> Thanks for all the f
Andor,
Il giorno lun 10 gen 2022 alle ore 15:17 Andor Molnar
ha scritto:
>
> Thanks for all the feedback and concerns folks. I’m trying organize them in
> bullet points. Order is random, not importance.
>
> 1) Licence. I’m not familiar with dual-licensing either. Maybe we need
> somebody with b
Thanks for all the feedback and concerns folks. I’m trying organize them in
bullet points. Order is random, not importance.
1) Licence. I’m not familiar with dual-licensing either. Maybe we need somebody
with better Apache knowledge around this or ask the legal team, I’m not sure.
Hope this won
On Fri, Jan 7, 2022 at 12:10 PM Ted Dunning wrote:
> I have been watching the private and public mailing lists for Apache
> Logging as part of $dayjob as well.
>
> I read the mood there differently. The most recent comment I remember was a
> confirmation that "no bugfixes or security patches are
I have been watching the private and public mailing lists for Apache
Logging as part of $dayjob as well.
I read the mood there differently. The most recent comment I remember was a
confirmation that "no bugfixes or security patches are planned for log4j1".
Log4j2 really is much larger than necess
Thanks Chris, et. al. I have been monitoring this thread already, but I
appreciate you following up. :-)
I checked out the log4j2 source repo as part of my remediation efforts
inside my employer. tbh I was/am shocked at the amount of code and esp the
number of dependencies, for something that shou
I just noticed that Patrick commented on ZOOKEEPER-2342 expressing doubt
about sticking with Log4J, so I want to make sure his perspective gets
included in our thread here. Specifically added him to the To: line.
Chris Nauroth
On Thu, Jan 6, 2022 at 11:16 PM Enrico Olivelli wrote:
> I believe
I believe that Chris points are valid.
My understanding, especially after seeing Andor's patch is that we are
depending on an implementation in two cases:
- in some tests (we grab the logs)
- for the binary tarbal (for real users if the server)
If we could rely on slf4j-simple for the tests (or w
Happy New Year, and thank you for driving this, Andor!
I am somewhat hesitant about switching direction to Logback:
- First, I agree with points already raised by Christopher.
- A major reason that my prior work to migrate to Log4J 2 in ZOOKEEPER-2342
stalled out years ago is backward-incompatibil
Hi folks,
Happy New Year!
Logback patch is now ready for review:
https://github.com/apache/zookeeper/pull/1793
Thanks,
Andor
> On 2021. Dec 21., at 20:44, Brent wrote:
>
> Thank you for the details Andor. It sounds like you have a good plan in
> place for doing the migration.
>
> I had so
Thank you for the details Andor. It sounds like you have a good plan in
place for doing the migration.
I had some open work against ZooInspector that I wanted to do, so it sounds
like I'd be best focusing my efforts there and leaving this to you.
Thanks for your time and help!
~Brent
On Tue, D
Andor,
Il giorno mar 21 dic 2021 alle ore 12:25 Andor Molnar ha
scritto:
> Thanks for the feedback Brent.
>
> I currently work on the logback patch and identified the following steps
> for migration:
> - Replace log4j references with logback counterparts in pom.xml,
> - Refactor unit tests which
Thanks for the feedback Brent.
I currently work on the logback patch and identified the following steps for
migration:
- Replace log4j references with logback counterparts in pom.xml,
- Refactor unit tests which depend on log4j: they create a custom
ByteArrayOutputStream for capturing log messag
In case it helps, I did a quick run over the weekend of all the places I
see "Log4j" mentioned in code and documentation. This is a naive search so
not all of these references are necessarily of equal impact, but I thought
it might give some context to the scope of the change. It also seems like
Apologies if this is repeated information (I sent some of this to the user@
mailing list).
I understand the arguments for/against Log4j 1.x and won't repeat them all
here. It seems like there's still some debate between Log4j2 vs. Logback
too. Does anyone have a feel for how much effort either o
Gosh, we have a few unit tests with log4j specific code.
I need some free cycles to refactor them properly.
Andor
> On 2021. Dec 15., at 14:11, Andor Molnar wrote:
>
> Agreed. My choice is not based on the recent vulnerabilities. There
> probably more to come by the way, so this is not the
Agreed. My choice is not based on the recent vulnerabilities. There
probably more to come by the way, so this is not the best timing for
log4j2.
Anyway, the main advantage I see for logback is that it's closer to
log4j1, hence probably easier to migrate to.
ZooKeeper already uses SLF4j so, as you
I think it would be a mistake to use the recently reported
vulnerability as a basis for migrating to logback. Any dependency can
have a vulnerability, and logback is not substantially different. No
dependency is going to be guaranteed vulnerability-free. Switching on
that basis is a wild goose chas
I think it is good to use Sl4j and provide the logback implementation.
This way users can use whatever framework they want to use
Enrico
Il giorno mer 15 dic 2021 alle ore 12:46 Andor Molnar ha
scritto:
> https://issues.apache.org/jira/browse/ZOOKEEPER-4427
>
>
> On Wed, 2021-12-15 at 12:35 +0
https://issues.apache.org/jira/browse/ZOOKEEPER-4427
On Wed, 2021-12-15 at 12:35 +0100, Andor Molnar wrote:
> Sure. I'll take care of that, but first things first. Look what I've
> found when checking the history of the issue.
>
> Thumbs-up from Ceki back from 2016:
>
> https://issues.apache.or
Sure. I'll take care of that, but first things first. Look what I've
found when checking the history of the issue.
Thumbs-up from Ceki back from 2016:
https://issues.apache.org/jira/browse/ZOOKEEPER-2342?focusedCommentId=15207288&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabp
+1
Would you like to submit a PR ?
Then we can release 3.8.0
Enrico
Il giorno mer 15 dic 2021 alle ore 12:04 Flavio Junqueira
ha scritto:
> We use logback in Pravega, it works fine for us. I'd be ok with the change.
>
> -Flavio
>
> > On 15 Dec 2021, at 12:02, Andor Molnar wrote:
> >
> > Hi ZK
We use logback in Pravega, it works fine for us. I'd be ok with the change.
-Flavio
> On 15 Dec 2021, at 12:02, Andor Molnar wrote:
>
> Hi ZK folks,
>
> What do you think about migrating ZK to logback?
> The idea just crossed my mind due to the recent turbulence with log4j.
>
> Checking some
47 matches
Mail list logo
