Skip to content

Conversation

@raboof
Copy link
Member

@raboof raboof commented Jan 10, 2025

Since logback 1.4.x requires Java 11

https://docs.github.com/en/code-security/dependabot/dependabot-version-updates/controlling-dependencies-updated#specifying-the-semantic-versioning-level-to-ignore

Supersedes #329 and #332

I don't think it makes sense to track this version in commons-parent, as relatively few commons projects seem to be using logback.

  • Read the contribution guidelines for this project.
  • Run a successful build using the default Maven goal with mvn; that's mvn on the command line by itself.
  • Write unit tests that match behavioral changes, where the tests fail if the changes to the runtime are not applied. This may not always be possible but is a best-practice.
  • Write a pull request description that is detailed enough to understand what the pull request does, how, and why.
  • Each commit in the pull request should have a meaningful subject line and body. Note that commits might be squashed by a maintainer on merge.

Copy link
Contributor

@ppkarwasz ppkarwasz left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM,

Remark: the recent CVE-2024-12798 and CVE-2024-12801 (that caused the Dependabot PRs for logback-core) seem pretty bogus to me: a Logback configuration file needs to be a trusted file, because it allows users to instantiate arbitrary classes by design.
IMHO "A successful attack requires the user to have write access to a configuration file" is synonymous to "An attacker that has write access to a Java application can execute arbitrary code."

@raboof
Copy link
Member Author

raboof commented Jan 10, 2025

Remark: the recent CVE-2024-12798 and CVE-2024-12801 (that caused the Dependabot PRs for logback-core) seem pretty bogus to me: a Logback configuration file needs to be a trusted file, because it allows users to instantiate arbitrary classes by design. IMHO "A successful attack requires the user to have write access to a configuration file" is synonymous to "An attacker that has write access to a Java application can execute arbitrary code."

sounds weird indeed, though the project seems to confirm the issues (https://logback.qos.ch/news.html#1.3.15)

@ppkarwasz
Copy link
Contributor

sounds weird indeed, though the project seems to confirm the issues (https://logback.qos.ch/news.html#1.3.15)

Probably Ceki didn't want to fight with windmills. Some projects, such as SnakeYAML are more firm in stating that CVEs do not apply to configuration files.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants