>I think we would
have to create a new repo and make the PR against the new repo
instead.
Why create a new repo? The current is just fine.
For instance, I migrated Apache JMeter from SVN to Git, and extra git
repositories were not needed.
See
https://issues.apache.org/jira/browse/INFRA-18499?foc
Severity: high
Description:
Apache Log4j2 versions 2.0-alpha1 through 2.16.0 did not protect from
uncontrolled recursion from self-referential lookups. This allows an
attacker with control over Thread Context Map data to cause a denial
of service when a crafted string is interpreted. This issue w
I think the current git repo is an SVN mirror, so there's no way to
merge from github into SVN(as far as I can tell). I think we would
have to create a new repo and make the PR against the new repo
instead.
Making a new git repo is now self-serve:
https://infra.apache.org/svn-to-git-migration.htm
I think Matt or somebody would just have to add your key to the KEYS file.
Otherwise, I have validated the checksums and the key, so +1 from me.
I did not validate that anything builds, as I don't do .NET.
-Robert Middleton
On Fri, Dec 17, 2021 at 5:53 AM Davyd McColl wrote:
>
> Hi Robert
>
> I
Hello everyone,
Please look at the RedHat CVE report made concerning log4j-v1 some time
ago: https://access.redhat.com/security/cve/cve-2017-5645
RedHat made the fix, presumably for the sake of RedHat users that for one
reason or another were stuck on log4j-v1. Once log4j-1 has moved to git
then i
Chainsaw was extracted into its own repository, so those changes are probably
ok at least.
—
Matt Sicker
> On Dec 18, 2021, at 12:17, Leo Simons wrote:
>
> On Sat, Dec 18, 2021 at 5:32 PM Leo Simons wrote:
>
>>> On Sat, Dec 18, 2021 at 3:34 PM Gary Gregory
>>> wrote:
>>>
>>> If you delete
I like this idea, but I think it would require non-default permissions for the
account the application runs under on windows. However, it could be feature
that can be switched on.
https://docs.microsoft.com/en-us/windows/security/threat-protection/security-policy-settings/create-symbolic-links
Again, you cannot break binary compatibility in a minor release. That's a
show stopper.
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 compl
On Sat, Dec 18, 2021 at 5:32 PM Leo Simons wrote:
> On Sat, Dec 18, 2021 at 3:34 PM Gary Gregory
> wrote:
>
>> If you delete anything that is public or protected, you will break
>> binary compatibility, and that's a no-go IMO.
>
>
> Agree. I hope we can get clirr (or something like it) back to w
Hey,
On Sat, Dec 18, 2021 at 1:52 PM Vladimir Sitnikov <
sitnikov.vladi...@gmail.com> wrote:
> >Similarly to set up git(hub) requires a PMC member.
> >Hopefully the [VOTE] on that is revisited and then someone sets it up.
>
> Would you please express your opinion on "[VOTE] Move log4j 1.x from SV
The Apache Log4j 2 team is pleased to announce the Log4j 2.17.0 release!
Apache Log4j is a well known framework for logging application behavior. Log4j
2 is an upgrade to Log4j that provides significant improvements over its
predecessor, Log4j 1.x, and provides many other modern features such as
+1 from me.
I imagine it should make it easier to make the security release when setup
for 1.2 is more similar to 2.x.
That should mean people who are good at releasing 2.x have an easy time
releasing 1.2.18.
I think we can (and should) do this in such a way that 1.2 EOL status
becomes *more* cle
Hey Gary,
On Sat, Dec 18, 2021 at 3:34 PM Gary Gregory wrote:
> If you delete anything that is public or protected, you will break
> binary compatibility, and that's a no-go IMO.
Agree. I hope we can get clirr (or something like it) back to work, to
prove binary compatibility.
Perhaps with on
Hi All:
And now for something completely different.
I wonder why we do not do file rollovers like below, and if we should:
- Create the file with the target rolled over a name like applog-2021.txt
- Create a symlink for the constant name like applog.txt to point to
applog-2021.txt
- When it's rol
If you delete anything that is public or protected, you will break
binary compatibility, and that's a no-go IMO. If are going to really
want to release anything, you'll want to disable JNDI by default and
add an enablement property as we did for 2.17.0.
Gary
On Sat, Dec 18, 2021 at 9:13 AM Robert
I can do the security release if something exists in a good state.
The reasoning for me is that there are still many applications that
exist that have not upgraded, even though it's been 6+ years.
If it is binary compatible as well, that makes upgrades easy(I'm
thinking of a case where you have an
>From my side what I volunteered for is to propose changes that should go in
>that fix for review.
Thank you.
>Similarly to set up git(hub) requires a PMC member.
>Hopefully the [VOTE] on that is revisited and then someone sets it up.
Would you please express your opinion on "[VOTE] Move log4j 1
Hey,
TL;DR: I have no intention to contribute anything but a security fix, and
I don't think there's anyone who thinks differently.
I'll provide a patch but won't/can't make the official release.
>From my side what I volunteered for is to propose changes that should go in
that fix for review.
I g
18 matches
Mail list logo
