Sure, we are on the same page about this RC. 

> On Dec 18, 2021, at 9:46 PM, 张铎 <palomino...@gmail.com> wrote:
> 
> I think we are on the same page that we should upgrade to the newest log4j2
> version since the final release has not been published yet.
> 
> But on log4j1, in our community we have discussed this before when there is
> a CVE for it. You can view this page
> 
> https://logging.apache.org/log4j/1.2/
> 
> And even for the recent CVE, log4j1 is also affected, as listed on the page
> you provided.
> 
> Log4j 1.x mitigation
> 
> Log4j 1.x does not have Lookups so the risk is lower. Applications using
> Log4j 1.x are only vulnerable to this attack when they use JNDI in their
> configuration. A separate CVE (CVE-2021-4104) has been filed for this
> vulnerability. To mitigate: Audit your logging configuration to ensure it
> has no JMSAppender configured. Log4j 1.x configurations without JMSAppender
> are not impacted by this vulnerability.
> 
> It is as you said in the first paragraph, log4j1 has a special CVE for it,
> and it will never be fixed. We need to say that ‘yes it is affected but
> only if you bla bla’, not good for end users right?
> 
> So I still stand my point that, stay on log4j1 is not a good choice, it is
> not because we have already done the work, it is our duty to keep our users
> safe from security problem.
> 
> And on the Hadoop part, it is also me that trying to upgrade to log4j2. But
> as you know Hadoop is actually constructed by several projects, it is
> really not easy to do this work, like what we have done in HBase.
> 
> Anyway, let me prepare a new RC.
> 
> Thanks.
> Andrew Purtell <andrew.purt...@gmail.com>于2021年12月19日 周日09:12写道:
> 
>> As to your first point, I think it is a simple consideration: A user’s
>> security department or compliance regulator will ask: “Does this version
>> include log4j with a known CVE?” Why would we provide a release where they
>> have to answer “yes” when we can provide them a release where they can
>> answer “no”? Based on todays knowledge. (And yes I am aware that a user can
>> manually upgrade the jar versions in place after unpacking the tarballs.
>> Nonetheless.)
>> 
>> I disagree that there was a real need to upgrade log4j because 1.x was EOL
>> but I won’t argue that staying with old dependencies is automatically good.
>> It’s done, anyway. The main point I would like to make here is should a
>> good alternative emerge from this mess I am going to look at replacing
>> log4j 2 with it. Or, if log4j decides to accept the inevitable and remove
>> the dangerous substitution/rewrite feature then that would be fine too.
>> 
>>>> On Dec 18, 2021, at 4:42 PM, 张铎 <palomino...@gmail.com> wrote:
>>> 
>>> After 2.15.0, all the problems require you manually put some special
>>> markers in the pattern layout in your configuration file, so it is
>> already
>>> less hurt, we do not have something like %m{lookup} in the pattern layout
>>> by default.
>>> 
>>> Anyway, since we haven’t released 3.0.0-alpha-2 yet, let’s upgrade to the
>>> newest version.
>>> 
>>> But stay on log4j1 should not be considered as a solution. Log4j1 is
>>> already dead long ago and it has several CVEs where no one wants to fix
>>> them, and our statement was just ‘do not use the feature’. That’s why we
>>> want to migrate to log4j2. Every project may have CVEs, so I think
>> whether
>>> there are still enough people who are still maintaining the project is
>> the
>>> most important thing. Log4j2 is already the most active logging
>> framework,
>>> another option is logback, but there were no releases for nearly 4 years
>>> before 2021…
>>> 
>>> Thanks. Let me upgrade the log4j2 to 2.17.0 and send out RC2.
>>> 
>>> Andrew Purtell <apurt...@apache.org>于2021年12月19日 周日05:25写道:
>>> 
>>>> Apologies, I managed to hit the send button before finishing. My veto
>> can
>>>> be cured by upgrading Log4J to ** 2.17.0 ** . See
>>>> https://logging.apache.org/log4j/2.x/security.html.
>>>> 
>>>>> On Sat, Dec 18, 2021 at 1:22 PM Andrew Purtell <apurt...@apache.org>
>>>>> wrote:
>>>>> 
>>>>> -1 (binding)
>>>>> 
>>>>> The Log4J issues are not fixed by 2.15.
>>>>> 
>>>>> I wish we had remained on Log4J 1. Hadoop 3 is still on 1, although I
>>>> know
>>>>> they have plans to upgrade. It does not seem advisable to use Log4J 2
>> at
>>>>> all actually. Another option that does not include such a dangerous
>>>>> reference/rewrite mechanism might be preferable.
>>>>> 
>>>>>> On Sat, Dec 18, 2021 at 12:02 PM Josh Elser <els...@apache.org>
>> wrote:
>>>>> 
>>>>>> +1 (binding)
>>>>>> 
>>>>>> * Xsums/sigs good
>>>>>> * Can build from source
>>>>>> * Log4j 2.15 is included (more on this in the below)
>>>>>> * log4j2.formatMsgNoLookups=true is set (multiple times per process,
>> but
>>>>>> properly set)
>>>>>> * hbase-config.sh issue is fixed over rc1
>>>>>> 
>>>>>> Best as I've been able to keep up, it seems like we should already
>>>>>> upgrade to log4j 2.16 due to issues in 2.15. There are alos rumblings
>>>>>> that 2.16 may have issues still. It's my opinion that the changes we
>>>>>> have here in rc2 are a massive improvement over before. I think this
>> is
>>>>>> fine; I just wanted to acknowledge that we may still need to update
>>>>>> again real soon.
>>>>>> 
>>>>>> Thanks for your release manager work, Duo!
>>>>>> 
>>>>>> On 12/14/21 9:06 AM, Duo Zhang wrote:
>>>>>>> Please vote on this Apache hbase release candidate,
>>>>>>> hbase-3.0.0-alpha-2RC1
>>>>>>> 
>>>>>>> The VOTE will remain open for at least 72 hours.
>>>>>>> 
>>>>>>> [ ] +1 Release this package as Apache hbase 3.0.0-alpha-2
>>>>>>> [ ] -1 Do not release this package because ...
>>>>>>> 
>>>>>>> The tag to be voted on is 3.0.0-alpha-2RC1:
>>>>>>> 
>>>>>>>  https://github.com/apache/hbase/tree/3.0.0-alpha-2RC1
>>>>>>> 
>>>>>>> This tag currently points to git reference
>>>>>>> 
>>>>>>>  a3ff8e4c812eefab6ad32af45ca449a1395a6510
>>>>>>> 
>>>>>>> The release files, including signatures, digests, as well as
>>>> CHANGES.md
>>>>>>> and RELEASENOTES.md included in this RC can be found at:
>>>>>>> 
>>>>>>>  https://dist.apache.org/repos/dist/dev/hbase/3.0.0-alpha-2RC1/
>>>>>>> 
>>>>>>> Maven artifacts are available in a staging repository at:
>>>>>>> 
>>>>>>> 
>>>>>> 
>> https://repository.apache.org/content/repositories/orgapachehbase-1473/
>>>>>>> 
>>>>>>> Artifacts were signed with the 9AD2AE49 key which can be found in:
>>>>>>> 
>>>>>>>  https://downloads.apache.org/hbase/KEYS
>>>>>>> 
>>>>>>> 3.0.0-alpha-2 is the second alpha release for our 3.0.0 major release
>>>>>> line.
>>>>>>> HBase 3.0.0 includes the following big feature/changes:
>>>>>>>  Synchronous Replication
>>>>>>>  OpenTelemetry Tracing
>>>>>>>  Distributed MOB Compaction
>>>>>>>  Backup and Restore
>>>>>>>  Move RSGroup balancer to core
>>>>>>>  Reimplement sync client on async client
>>>>>>>  CPEPs on shaded proto
>>>>>>>  Move the logging framework from log4j to log4j2
>>>>>>> 
>>>>>>> 3.0.0-alpha-2 contains a critical security fix for addressing the
>>>> log4j2
>>>>>>> CVE-2021-44228. All users who already use 3.0.0-alpha-1 should
>> upgrade
>>>>>>> to 3.0.0-alpha-2 ASAP.
>>>>>>> 
>>>>>>> Notice that this is not a production ready release. It is used to let
>>>>>> our
>>>>>>> users try and test the new major release, to get feedback before the
>>>>>> final
>>>>>>> GA release is out.
>>>>>>> So please do NOT use it in production. Just try it and report back
>>>>>>> everything you find unusual.
>>>>>>> 
>>>>>>> And this time we will not include CHANGES.md and RELEASENOTE.md
>>>>>>> in our source code, you can find it on the download site. For getting
>>>>>> these
>>>>>>> two files for old releases, please go to
>>>>>>> 
>>>>>>>  https://archive.apache.org/dist/hbase/
>>>>>>> 
>>>>>>> To learn more about Apache hbase, please see
>>>>>>> 
>>>>>>>  http://hbase.apache.org/
>>>>>>> 
>>>>>>> Thanks,
>>>>>>> Your HBase Release Manager
>>>>>>> 
>>>>>> 
>>>>> 
>>>>> 
>>>>> --
>>>>> Best regards,
>>>>> Andrew
>>>>> 
>>>>> Words like orphans lost among the crosstalk, meaning torn from truth's
>>>>> decrepit hands
>>>>>  - A23, Crosstalk
>>>>> 
>>>> 
>>>> 
>>>> --
>>>> Best regards,
>>>> Andrew
>>>> 
>>>> Words like orphans lost among the crosstalk, meaning torn from truth's
>>>> decrepit hands
>>>>  - A23, Crosstalk
>>>> 
>> 

Reply via email to