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

Configure dependabot to only propose logback patch versions #335

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

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."

.github/dependabot.yml Outdated Show resolved Hide resolved
@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