[GitHub] [logging-log4j1] lsimons closed pull request #17: Cleaned-up log4j 1.2 that disables scary networking (base=1.2.17, fully binary compatible)
lsimons closed pull request #17: URL: https://github.com/apache/logging-log4j1/pull/17 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@logging.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [logging-log4j1] lsimons commented on pull request #17: Cleaned-up log4j 1.2 that disables scary networking (base=1.2.17, fully binary compatible)
lsimons commented on pull request #17: URL: https://github.com/apache/logging-log4j1/pull/17#issuecomment-1003669830 Superceded by #18 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@logging.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
Re: [DISCUSS][VOTE] Future of Log4j 1.x
Hey, Happy new year everyone! On Wed, Dec 29, 2021 at 8:54 PM Ralph Goers wrote: > Leo seemed interested at first but didn’t weigh in on the discussion > thread. I'm here. I did mention in a couple mails I'd be away. Real life happens :). I think I made clear what I am interested in through several emails and in code. I've also pointed out what I wouldn't do (like step up as a maintainer on a permanent basis, or incubate something). I think all the relevant arguments on how to proceed with 1.x have been made (a few times...). I don't have anything new to add. I'll accept the vote outcome. Cheers! Leo
[GitHub] [logging-log4j1] lsimons commented on pull request #17: Cleaned-up log4j 1.2 that disables scary networking (base=1.2.17, fully binary compatible)
lsimons commented on pull request #17: URL: https://github.com/apache/logging-log4j1/pull/17#issuecomment-1003669519 The rationale is not found here because most discussion about what should happen with apache projects happens on mailing lists. In this case, the discussion can be followed (and joined!) on dev@logging.apache.org, archives at https://lists.apache.org/list.html?dev@logging.apache.org , more info at https://logging.apache.org/log4j/2.x/mail-lists.html . -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@logging.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
Re: [VOTE] Future of Log4j 1.x
I’m +1 for option one. For projects that ignored published CVEs for multiple years and then ignored the EOL announcement, I don’t see any reason they’d bother updating their ancient copies. Given the release difficulty in making something that’s compatible with previous releases makes this even more of a waste of time. — Matt Sicker > On Jan 1, 2022, at 11:20, Jochen Wiedmann wrote: > > On Sat, Jan 1, 2022 at 4:40 PM Xeno Amess wrote: > >>> People should migrate to log4j2. >> good thinking, but what if they migrate to logback... > > No, it's not (good thinking, that is). > > Log4j1 is a part of basically *every* Java based server software, that > I am aware of. People don't want to touch those. They need a drop-in > replacement, not a successor. Over the last week, I was *really > puzzled* about all the stuff that claims to be affected by the > problems in log4j2. And that's the lesser used of the two... > > Jochen > > > > Philosophy is useless, theology is worse. (Industrial Desease, Dire Straits)
Re: [log4cxx] Short filename options
This is already provided by
```
#define LOG4CXX_LOCATION ::log4cxx::spi::LocationInfo()
#include
```
On Sun, Jan 2, 2022 at 12:38 PM Robert Middleton
wrote:
> The full path is already in the compiled code anyway, this would
> simply add the ability to get the filename from the full path(so
> another member to the LocationInfo class). I can see certain
> circumstances where it is useful to have the full path, for example
> when you have two files named the same(please don't do this).
>
> That does bring up a good point though, is that if you don't want
> location info compiled in, we should have a preprocessor macro that
> will compile out all of the location info data. We can already
> compile out log messages of certain levels, so hiding the location is
> just a natural extension of that.
>
> -Robert Middleton
>
> On Sat, Jan 1, 2022 at 7:50 PM Stephen Webb wrote:
> >
> > I prefer option 2 if it is possible.
> >
> > I do not think it is useful to have the full path name (of the build
> > directory) in shipped binaries.
> >
> > On Sun, Jan 2, 2022 at 7:11 AM Robert Middleton
> > wrote:
> >
> > > PR #75 adds a new option for displaying the short filename of the log
> > > location, which is probably a good idea to have, as in my experience,
> > > the whole path of the file is not that useful, especially when the
> > > binary is from a build server where the path is something like
> > > /var/lib/jenkins/project-name/src/main/directory/foo.cpp.
> > >
> > > The current PR does this with some string manipulation at runtime, and
> > > is different from the const char* that is currently used, so it
> > > doesn't fit that well with the rest of the class. Since C++11 we can
> > > now do constexpr functions, so we should be able to do this at compile
> > > time(assuming you have optimizations turned on of course).
> > >
> > > We can do this one of several ways:
> > > 1. Take the PR as is(use strings and calculate at runtime)
> > > 2. Create a constexpr function that we control to calculate the
> > > filename at compile time as either an offset into the filename or a
> > > separate const char*. The advantage to this is that it doesn't
> > > require any other libraries for pre-C++17 compilers.
> > > 3. Use std::string_view(for C++17) or boost::string_view(pre-c++17).
> > > The following would work for this solution:
> > > std::string_view str{"/foo/bar/what.cpp"};
> > > const int location = str.find_last_of( '/' ) + 1;
> > > printf( "fullPath: %s\n", str.data() );
> > > printf( "fileName: %s\n", [location] );
> > >
> > > Does anybody have a preference or a better way to do it? I'm inclined
> > > to go with (3), since that does provide a good fallback for compilers
> > > that don't support C++17, and only requires boost for older compilers.
> > >
> > > -Robert Middleton
> > >
>
Re: [log4cxx] Short filename options
The full path is already in the compiled code anyway, this would
simply add the ability to get the filename from the full path(so
another member to the LocationInfo class). I can see certain
circumstances where it is useful to have the full path, for example
when you have two files named the same(please don't do this).
That does bring up a good point though, is that if you don't want
location info compiled in, we should have a preprocessor macro that
will compile out all of the location info data. We can already
compile out log messages of certain levels, so hiding the location is
just a natural extension of that.
-Robert Middleton
On Sat, Jan 1, 2022 at 7:50 PM Stephen Webb wrote:
>
> I prefer option 2 if it is possible.
>
> I do not think it is useful to have the full path name (of the build
> directory) in shipped binaries.
>
> On Sun, Jan 2, 2022 at 7:11 AM Robert Middleton
> wrote:
>
> > PR #75 adds a new option for displaying the short filename of the log
> > location, which is probably a good idea to have, as in my experience,
> > the whole path of the file is not that useful, especially when the
> > binary is from a build server where the path is something like
> > /var/lib/jenkins/project-name/src/main/directory/foo.cpp.
> >
> > The current PR does this with some string manipulation at runtime, and
> > is different from the const char* that is currently used, so it
> > doesn't fit that well with the rest of the class. Since C++11 we can
> > now do constexpr functions, so we should be able to do this at compile
> > time(assuming you have optimizations turned on of course).
> >
> > We can do this one of several ways:
> > 1. Take the PR as is(use strings and calculate at runtime)
> > 2. Create a constexpr function that we control to calculate the
> > filename at compile time as either an offset into the filename or a
> > separate const char*. The advantage to this is that it doesn't
> > require any other libraries for pre-C++17 compilers.
> > 3. Use std::string_view(for C++17) or boost::string_view(pre-c++17).
> > The following would work for this solution:
> > std::string_view str{"/foo/bar/what.cpp"};
> > const int location = str.find_last_of( '/' ) + 1;
> > printf( "fullPath: %s\n", str.data() );
> > printf( "fileName: %s\n", [location] );
> >
> > Does anybody have a preference or a better way to do it? I'm inclined
> > to go with (3), since that does provide a good fallback for compilers
> > that don't support C++17, and only requires boost for older compilers.
> >
> > -Robert Middleton
> >
Re: [log4cxx] Short filename options
I prefer option 2 if it is possible.
I do not think it is useful to have the full path name (of the build
directory) in shipped binaries.
On Sun, Jan 2, 2022 at 7:11 AM Robert Middleton
wrote:
> PR #75 adds a new option for displaying the short filename of the log
> location, which is probably a good idea to have, as in my experience,
> the whole path of the file is not that useful, especially when the
> binary is from a build server where the path is something like
> /var/lib/jenkins/project-name/src/main/directory/foo.cpp.
>
> The current PR does this with some string manipulation at runtime, and
> is different from the const char* that is currently used, so it
> doesn't fit that well with the rest of the class. Since C++11 we can
> now do constexpr functions, so we should be able to do this at compile
> time(assuming you have optimizations turned on of course).
>
> We can do this one of several ways:
> 1. Take the PR as is(use strings and calculate at runtime)
> 2. Create a constexpr function that we control to calculate the
> filename at compile time as either an offset into the filename or a
> separate const char*. The advantage to this is that it doesn't
> require any other libraries for pre-C++17 compilers.
> 3. Use std::string_view(for C++17) or boost::string_view(pre-c++17).
> The following would work for this solution:
> std::string_view str{"/foo/bar/what.cpp"};
> const int location = str.find_last_of( '/' ) + 1;
> printf( "fullPath: %s\n", str.data() );
> printf( "fileName: %s\n", [location] );
>
> Does anybody have a preference or a better way to do it? I'm inclined
> to go with (3), since that does provide a good fallback for compilers
> that don't support C++17, and only requires boost for older compilers.
>
> -Robert Middleton
>
Re: [VOTE] Future of Log4j 1.x
On Sat, Jan 1, 2022, at 18:19, Jochen Wiedmann wrote: > On Sat, Jan 1, 2022 at 4:40 PM Xeno Amess wrote: > >> > People should migrate to log4j2. >> good thinking, but what if they migrate to logback... > > No, it's not (good thinking, that is). > > Log4j1 is a part of basically *every* Java based server software, that > I am aware of. People don't want to touch those. They need a drop-in > replacement, not a successor. Over the last week, I was *really > puzzled* about all the stuff that claims to be affected by the > problems in log4j2. And that's the lesser used of the two... For what exactly do we need that now? The security issues in log4j1 are 10 years old and you just don't have to use JMSAppender and you are good too go. Cheers, Christian > Jochen > > > > Philosophy is useless, theology is worse. (Industrial Desease, Dire Straits)
[log4cxx] Short filename options
PR #75 adds a new option for displaying the short filename of the log
location, which is probably a good idea to have, as in my experience,
the whole path of the file is not that useful, especially when the
binary is from a build server where the path is something like
/var/lib/jenkins/project-name/src/main/directory/foo.cpp.
The current PR does this with some string manipulation at runtime, and
is different from the const char* that is currently used, so it
doesn't fit that well with the rest of the class. Since C++11 we can
now do constexpr functions, so we should be able to do this at compile
time(assuming you have optimizations turned on of course).
We can do this one of several ways:
1. Take the PR as is(use strings and calculate at runtime)
2. Create a constexpr function that we control to calculate the
filename at compile time as either an offset into the filename or a
separate const char*. The advantage to this is that it doesn't
require any other libraries for pre-C++17 compilers.
3. Use std::string_view(for C++17) or boost::string_view(pre-c++17).
The following would work for this solution:
std::string_view str{"/foo/bar/what.cpp"};
const int location = str.find_last_of( '/' ) + 1;
printf( "fullPath: %s\n", str.data() );
printf( "fileName: %s\n", [location] );
Does anybody have a preference or a better way to do it? I'm inclined
to go with (3), since that does provide a good fallback for compilers
that don't support C++17, and only requires boost for older compilers.
-Robert Middleton
[GitHub] [logging-log4j1] rgoers commented on pull request #18: Refine build scripts
rgoers commented on pull request #18: URL: https://github.com/apache/logging-log4j1/pull/18#issuecomment-1003592080 @larrywest There has not been a decision to reverse this. There has been a request to reverse it. We just realized that when we made the subversion repo read-only that there was mirror at GitHub that people were making PRs to. That GitHub repo was not under the control of the Apache Logging project so we moved it here. Discussions have been happening on the dev list and there is currently a vote in progress between two options. The Logging Services PMC hasn't committed to doing anything as of yet. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@logging.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [logging-log4j1] vlsi commented on pull request #18: Refine build scripts
vlsi commented on pull request #18: URL: https://github.com/apache/logging-log4j1/pull/18#issuecomment-1003591827 @larrywest , log4j 1.2 is still used a lot, and there's no drop-in replacement. That is why fixing 1.2 makes perfect sense, so the users can just upgrade log4j 1.x to a newer version and avoid spending time on migrating to another libraries. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@logging.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [logging-log4j1] larrywest commented on pull request #18: Refine build scripts
larrywest commented on pull request #18: URL: https://github.com/apache/logging-log4j1/pull/18#issuecomment-1003591272 @jvz Sorry if this is stated somewhere I missed, but [what's the reason for reversing the end-of-life decision for log4j 1.x](https://github.com/apache/logging-log4j1/pull/17#issuecomment-1003588369)? -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@logging.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [logging-log4j1] larrywest edited a comment on pull request #17: Cleaned-up log4j 1.2 that disables scary networking (base=1.2.17, fully binary compatible)
larrywest edited a comment on pull request #17: URL: https://github.com/apache/logging-log4j1/pull/17#issuecomment-1003588369 _My $0.02:_ Log4j 1.x reached end-of-life long ago - last updated a decade ago. > On August 5, 2015 the Logging Services Project Management Committee announced that Log4j 1.x had reached end of life From 2019 in re CVE-2019-17571: > ... This can provide an attack vector that can be expoited. Since Log4j 1 is no longer maintained this issue will not be fixed. Users are urged to upgrade to Log4j 2. * https://logging.apache.org/log4j/1.2/ * https://blogs.apache.org/foundation/entry/apache_logging_services_project_announces * https://blogs.apache.org/logging/entry/moving_on_to_log4j_2 There's no rationale given here for bringing log4j 1.x back from the dead, and anyone who cares about security or project hygiene has long since moved on to log4j2 or logback. Assuming there are reasons, why not fork this and call it something else? --- _Update:_ This applies to PR #18, too. I'm only a user — once upon a time of log4j 1.x — not a contributor, but I'm puzzled why there's not a clear statement on either PR justifying reversing the above-cited decisions. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@logging.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
Re: [VOTE] Future of Log4j 1.x
On Sat, Jan 1, 2022 at 4:40 PM Xeno Amess wrote: > > People should migrate to log4j2. > good thinking, but what if they migrate to logback... No, it's not (good thinking, that is). Log4j1 is a part of basically *every* Java based server software, that I am aware of. People don't want to touch those. They need a drop-in replacement, not a successor. Over the last week, I was *really puzzled* about all the stuff that claims to be affected by the problems in log4j2. And that's the lesser used of the two... Jochen Philosophy is useless, theology is worse. (Industrial Desease, Dire Straits)
[GitHub] [logging-log4j1] larrywest commented on pull request #17: Cleaned-up log4j 1.2 that disables scary networking (base=1.2.17, fully binary compatible)
larrywest commented on pull request #17: URL: https://github.com/apache/logging-log4j1/pull/17#issuecomment-1003588369 _My $0.02:_ Log4j 1.x reached end-of-life long ago - last updated a decade ago. > On August 5, 2015 the Logging Services Project Management Committee announced that Log4j 1.x had reached end of life From 2019 in re CVE-2019-17571: > ... This can provide an attack vector that can be expoited. Since Log4j 1 is no longer maintained this issue will not be fixed. Users are urged to upgrade to Log4j 2. * https://logging.apache.org/log4j/1.2/ * https://blogs.apache.org/foundation/entry/apache_logging_services_project_announces There's no rationale given here for bringing log4j 1.x back from the dead, and anyone who cares about security or project hygiene has long since moved on to log4j2 or logback. Assuming there are reasons, why not fork this and call it something else? -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@logging.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[DISCUSS][VOTE] Future of Log4j 1.x
Discussion shouldn’t happen on the main vote thread please. Users are certainly free to use Logback. If they are OK with losing log events during reconfiguration and using a framework that is maintained by one person and are OK when he disappears for a year and a half that is their choice. Please remember, this is not a commercial venture. No Java logging framework is. Switching to Logback also requires work. It doesn’t natively support Log4j 1 configuration files. Log4j 2 does support Log4j 1 configuration using the Log4j 1.2 bridge, which we are constantly improving. But the bottom line is that I would prefer that users migrate to Logback over sticking with Log4j 1. Although it has many of Log4j 1’s flaws it does not suffer from the multi-threading issues that Log4j 1 has. Of course, I think Log4j 2 is a better choice, but I am obviously biased. Happy New Year! Ralph > On Jan 1, 2022, at 8:40 AM, Xeno Amess wrote: > > +0 > >> People should migrate to log4j2. > good thinking, but what if they migrate to logback... > IMO logback is a thing more likely log4j1 than log4j2, just user side. > > > Ralph Goers 于2022年1月1日周六 23:18写道： > >> +1 to Option 1 >> >> Ralph >> >>> On Dec 29, 2021, at 12:33 PM, Christian Grobmeier >> wrote: >>> >>> Hello, >>> >>> as discussed in another thread, this is a vote about the future of log4j >> 1. This vote stays open for the usual 72h. >>> Options are explained below. >>> >>> You can vote for: >>> >>> [ ] +1, Option 1 >>> [ ] +1, Option 2 >>> [ ] +/- 0, abstain >>> [ ] -1 object against those options >>> >>> Option 1: Create a README.md that publishes the projects EOL status and >> do nothing else. >>> Option 2: Create a README which says the project is EOL but allow the >> following work for 1.2.18 AND create a full release: >>> a. Make the build work with a modern version of Maven. >>> b. Fix the Java version bug. >>> c. Fix CVE-2021-4104 (expanded to address all JNDI components) >>> d. Fix CVE-2019-17571 >>> >>> Regards, >>> Christian >>> -- >>> The Apache Software Foundation >>> V.P., Data Privacy >>> >> >>
Re: [VOTE] Future of Log4j 1.x
+0 > People should migrate to log4j2. good thinking, but what if they migrate to logback... IMO logback is a thing more likely log4j1 than log4j2, just user side. Ralph Goers 于2022年1月1日周六 23:18写道： > +1 to Option 1 > > Ralph > > > On Dec 29, 2021, at 12:33 PM, Christian Grobmeier > wrote: > > > > Hello, > > > > as discussed in another thread, this is a vote about the future of log4j > 1. This vote stays open for the usual 72h. > > Options are explained below. > > > > You can vote for: > > > > [ ] +1, Option 1 > > [ ] +1, Option 2 > > [ ] +/- 0, abstain > > [ ] -1 object against those options > > > > Option 1: Create a README.md that publishes the projects EOL status and > do nothing else. > > Option 2: Create a README which says the project is EOL but allow the > following work for 1.2.18 AND create a full release: > >a. Make the build work with a modern version of Maven. > >b. Fix the Java version bug. > >c. Fix CVE-2021-4104 (expanded to address all JNDI components) > >d. Fix CVE-2019-17571 > > > > Regards, > > Christian > > -- > > The Apache Software Foundation > > V.P., Data Privacy > > > >
Re: [DISCUSS][VOTE] Future of Log4j 1.x
These show up as two distinct threads In Mail on my MacBook Pro. FWIW, the PMC is aware of at least two distributions that already seem to fulfill the need of providing patched versions of Log4 1: 1. https://github.com/albfernandez/log4j/ 2. https://search.maven.org/artifact/io.confluent/confluent-log4j (The source appears to be in a private repository). Of course, both of these use different maven coordinates than Apache Log4j so users will have to ensure they exclude the Apache Log4j dependencies. Ralph > On Dec 30, 2021, at 5:23 AM, Vladimir Sitnikov > wrote: > > Christian>vote in this thread, which is, btw not meant for discussion but > for voting. > > We are on a [DISCUSS] thread (check the subject). > > Ralph "created" [DISCUSS] thread by hitting "reply" and changing the > subject. > "reply" keeps message-id, so it might look like a single thread. > > See both "[DISCUSS][VOTE] Future of Log4j 1.x" and "[VOTE] Future of Log4j > 1.x" > at https://lists.apache.org/list.html?dev@logging.apache.org > > Vladimir
Re: [VOTE] Future of Log4j 1.x
+1 to Option 1 Ralph > On Dec 29, 2021, at 12:33 PM, Christian Grobmeier > wrote: > > Hello, > > as discussed in another thread, this is a vote about the future of log4j 1. > This vote stays open for the usual 72h. > Options are explained below. > > You can vote for: > > [ ] +1, Option 1 > [ ] +1, Option 2 > [ ] +/- 0, abstain > [ ] -1 object against those options > > Option 1: Create a README.md that publishes the projects EOL status and do > nothing else. > Option 2: Create a README which says the project is EOL but allow the > following work for 1.2.18 AND create a full release: >a. Make the build work with a modern version of Maven. >b. Fix the Java version bug. >c. Fix CVE-2021-4104 (expanded to address all JNDI components) >d. Fix CVE-2019-17571 > > Regards, > Christian > -- > The Apache Software Foundation > V.P., Data Privacy >
