Configure dependabot to only propose logback patch versions

[raboof]

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.

• [x] 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.
• [x] Write a pull request description that is detailed enough to understand what the pull request does, how, and why.
• [x] 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.

[raboof]

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]

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.