Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Use Pax Logging 2.0.13 #1354

Merged
merged 1 commit into from
Dec 19, 2021
Merged

Use Pax Logging 2.0.13 #1354

merged 1 commit into from
Dec 19, 2021

Conversation

wborn
Copy link
Member

@wborn wborn commented Dec 19, 2021

Pax Logging 2.0.13 uses log4j2 2.17 which fixes CVE-2021-45105.

Also-by: Łukasz Dywicki [email protected]
Signed-off-by: Wouter Born [email protected]

Pax Logging 2.0.13 uses log4j2 2.17 which fixes CVE-2021-45105.

Also-by: Łukasz Dywicki <[email protected]>
Signed-off-by: Wouter Born <[email protected]>
@wborn wborn requested a review from a team as a code owner December 19, 2021 16:35
@wborn wborn mentioned this pull request Dec 19, 2021
@kaikreuzer kaikreuzer merged commit cd3302f into openhab:main Dec 19, 2021
@kaikreuzer kaikreuzer added this to the 3.2 milestone Dec 19, 2021
@wborn wborn deleted the pax-logging-2.0.13 branch December 19, 2021 16:39
@wborn wborn added the security label Dec 19, 2021
@kaikreuzer
Copy link
Member

kaikreuzer commented Dec 19, 2021

@wborn This now results for me in these errors at startup:

        Caused by: java.io.IOException: Error resolving artifact org.ops4j.pax.logging:pax-logging-log4j2:jar:2.0.12: [Could not find artifact org.ops4j.pax.logging:pax-logging-log4j2:jar:2.0.12 in openhab (https://openhab.jfrog.io/openhab/libs-snapshot/)]
                at org.ops4j.pax.url.mvn.internal.AetherBasedResolver.configureIOException(AetherBasedResolver.java:803)
                at org.ops4j.pax.url.mvn.internal.AetherBasedResolver.resolve(AetherBasedResolver.java:774)
                at org.ops4j.pax.url.mvn.internal.AetherBasedResolver.resolve(AetherBasedResolver.java:657)
                at org.ops4j.pax.url.mvn.internal.AetherBasedResolver.resolve(AetherBasedResolver.java:598)
                at org.ops4j.pax.url.mvn.internal.AetherBasedResolver.resolve(AetherBasedResolver.java:565)
                at org.apache.karaf.features.internal.download.impl.MavenDownloadTask.download(MavenDownloadTask.java:52)
                at org.apache.karaf.features.internal.download.impl.AbstractRetryableDownloadTask.run(AbstractRetryableDownloadTask.java:60)
                ... 6 more

This sounds as if the bundle is not being packaged with the distro?
I'm not sure why the distro still tries to find that (old) bundle version)?

@kaikreuzer
Copy link
Member

The file

runtime/system/org/apache/karaf/features/framework/4.3.4/framework-4.3.4-features.xml

still lists

30:        <bundle start-level="8">mvn:org.ops4j.pax.logging/pax-logging-api/2.0.12</bundle>
56:        <bundle start-level="8">mvn:org.ops4j.pax.logging/pax-logging-api/2.0.12</bundle>

so the bundleReplacements does not seem to work as expected. @splatch Any idea?

@wborn
Copy link
Member Author

wborn commented Dec 19, 2021

I don't see this exception and it uses the updated bundles:

openhab> bundle:list -t 0 -s |grep pax-logging
  5 │ Active   │   8 │ 2.0.13                  │ org.ops4j.pax.logging.pax-logging-api
  7 │ Active   │   8 │ 2.0.13                  │ org.ops4j.pax.logging.pax-logging-log4j2

@kaikreuzer
Copy link
Member

I actually have quite some other hits:

runtime/bin/instance
83:    CLASSPATH="${CLASSPATH}:${KARAF_HOME}/system/org/ops4j/pax/logging/pax-logging-api/2.0.12/pax-logging-api-2.0.12.jar"

runtime/bin/instance.bat
157:set CLASSPATH=%CLASSPATH%;%KARAF_HOME%\system\org\ops4j\pax\logging\pax-logging-api\2.0.12\pax-logging-api-2.0.12.jar

runtime/bin/shell
82:    CLASSPATH="${CLASSPATH}:${KARAF_HOME}/system/org/ops4j/pax/logging/pax-logging-api/2.0.12/pax-logging-api-2.0.12.jar"

runtime/bin/shell.bat
141:set CLASSPATH=%CLASSPATH%;%KARAF_HOME%\system\org\ops4j\pax\logging\pax-logging-api\2.0.12\pax-logging-api-2.0.12.jar

runtime/system/org/apache/karaf/features/framework/4.3.4/framework-4.3.4-features.xml
30:        <bundle start-level="8">mvn:org.ops4j.pax.logging/pax-logging-api/2.0.12</bundle>
31:        <bundle start-level="8">mvn:org.ops4j.pax.logging/pax-logging-log4j2/2.0.12</bundle>
56:        <bundle start-level="8">mvn:org.ops4j.pax.logging/pax-logging-api/2.0.12</bundle>
57:        <bundle start-level="8">mvn:org.ops4j.pax.logging/pax-logging-logback/2.0.12</bundle>

Can you confirm that all these already reference 2.0.13 in your case, @wborn?

@wborn
Copy link
Member Author

wborn commented Dec 19, 2021

These still also reference 2.0.12 for me but I don't see any exceptions.

We could remove the exclude again so the JAR is still there for the scripts that really depend on it:

https://github.com/openhab/openhab-distro/blob/main/distributions/openhab/src/main/descriptors/archive.xml#L54-L56

@kaikreuzer
Copy link
Member

I don't think the exceptions come from the script, but rather from the framework-4.3.4-features.xml file... And this would mean that even the runtime would then still use the old version, so we could equally revert the whole PR then.

@wborn
Copy link
Member Author

wborn commented Dec 19, 2021

I'm fine with reverting it, better safe than sorry. 😉

@J-N-K
Copy link
Member

J-N-K commented Dec 19, 2021

Isn't the featureProcessing just about replacing the dependency in the XML with the new version? And wouldn't it be possible to update the version in the scripts as well?

@wborn
Copy link
Member Author

wborn commented Dec 19, 2021

Perhaps it works better when this line is uncommented:

@kaikreuzer
Copy link
Member

Changing this manually on my install does not make a difference.
When is the processing supposed to happen? I thought that's done at build time already, while this setting is rather a runtime setting, isn't it?

@kaikreuzer
Copy link
Member

A fresh install indeed works as expected.
The difference is the file userdata/etc/org.apache.karaf.features.xml, which is not overwritten by a distro update.
My "old" version is:

    <blacklistedRepositories>
        <repository>mvn:org.apache.karaf.features/framework/4.3.0-SNAPSHOT/xml/features</repository>
        <repository>mvn:org.apache.karaf.features/standard/4.3.0-SNAPSHOT/xml/features</repository>
        <repository>mvn:org.apache.karaf.features/enterprise/4.3.0-SNAPSHOT/xml/features</repository>
        <repository>mvn:org.apache.karaf.features/enterprise-legacy/4.3.0-SNAPSHOT/xml/features</repository>
        <repository>mvn:org.apache.karaf.features/spring/4.3.0-SNAPSHOT/xml/features</repository>
        <repository>mvn:org.apache.karaf.features/spring-legacy/4.3.0-SNAPSHOT/xml/features</repository>
    </blacklistedRepositories>

while the new one now contains instead:

    <bundleReplacements>
        <bundle originalUri="mvn:org.ops4j.pax.logging/pax-logging-api/[0,2.0.13)" replacement="mvn:org.ops4j.pax.logging/pax-logging-api/2.0.13" mode="maven" />
        <bundle originalUri="mvn:org.ops4j.pax.logging/pax-logging-log4j2/[0,2.0.13)" replacement="mvn:org.ops4j.pax.logging/pax-logging-log4j2/2.0.13" mode="maven" />
        <bundle originalUri="mvn:org.ops4j.pax.logging/pax-logging-logback/[0,2.0.13)" replacement="mvn:org.ops4j.pax.logging/pax-logging-logback/2.0.13" mode="maven" />
    </bundleReplacements>

@wborn
Copy link
Member Author

wborn commented Dec 19, 2021

Yes that's also what it looks like for me all the time. I did a clean install. 😉

We could add it to https://github.com/openhab/openhab-distro/blob/main/distributions/openhab/src/main/resources/bin/userdata_sysfiles.lst so it is overwritten and add also add the scripts that have it in their classpath to the repo.

@kaikreuzer
Copy link
Member

Yeah, I thought the same: #1355

@wborn
Copy link
Member Author

wborn commented Dec 19, 2021

But it could also be that I don't run into these download issues because I run it on my desktop and it contains pax-logging 2.0.12 in the local Maven repo 😐

@kaikreuzer
Copy link
Member

Wrt instance and shell scripts: They are created by the Karaf packaging itself, so we cannot easily fix them. But I am not sure if they work with openHAB at all as we do not use these (but only the karaf script). Shall we just ignore them?

@wborn
Copy link
Member Author

wborn commented Dec 19, 2021

Shall we just ignore them?

If we don't use them I also think they can be ignored. The runtime starts without issues and the client script also works fine.

It still seems to work fine if I remove the pax-logging artifacts from my local Maven repo.

@splatch
Copy link
Contributor

splatch commented Dec 19, 2021

Sorry gents, missed your concerns.

I don't think the exceptions come from the script, but rather from the framework-4.3.4-features.xml file... And this would mean that even the runtime would then still use the old version, so we could equally revert the whole PR then.

@kaikreuzer feature processing can work at runtime but then you need properly configured maven repos to pull replacement bundle.

I actually have quite some other hits:

These scripts are not usable with OH cause of directory layout anyways, so you can ignore them.

@kaikreuzer
Copy link
Member

Latest distro build looks fine now, even for an update!

@openhab-bot
Copy link
Collaborator

This pull request has been mentioned on openHAB Community. There might be relevant details there:

https://community.openhab.org/t/openhab-3-2-release-discussion/130327/8

@openhab-bot
Copy link
Collaborator

This pull request has been mentioned on openHAB Community. There might be relevant details there:

https://community.openhab.org/t/openhab-3-2-release-discussion/130327/9

@openhab-bot
Copy link
Collaborator

This pull request has been mentioned on openHAB Community. There might be relevant details there:

https://community.openhab.org/t/issues-with-running-openhab-3-2-docker-image/130368/3

wborn added a commit to wborn/openhab-distro that referenced this pull request Jan 15, 2022
* Syncs distro customizations with Karaf 4.3.6
* Resolves app runbundles for the new dependencies
* Undos the featuresProcessing for using Pax Logging 2.0.13 (openhab#1354)

For release notes, see:

https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311140&version=12351123

Karaf 4.3.6 uses Pax Logging 2.0.14 (with Log4j 2.17.1) which fixes CVE-2021-44832.

Signed-off-by: Wouter Born <[email protected]>
@wborn wborn mentioned this pull request Jan 15, 2022
kaikreuzer pushed a commit that referenced this pull request Jan 16, 2022
* Syncs distro customizations with Karaf 4.3.6
* Resolves app runbundles for the new dependencies
* Undos the featuresProcessing for using Pax Logging 2.0.13 (#1354)

For release notes, see:

https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311140&version=12351123

Karaf 4.3.6 uses Pax Logging 2.0.14 (with Log4j 2.17.1) which fixes CVE-2021-44832.

Signed-off-by: Wouter Born <[email protected]>
@openhab-bot
Copy link
Collaborator

This pull request has been mentioned on openHAB Community. There might be relevant details there:

https://community.openhab.org/t/failing-dsc-binding-installation/139749/3

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants