- The `PDFBox` documentation points out that `log4j` is not needed (though `commons-logging` is) and that logging will "fall back to the standard java.util.logging API included in the Java platform"
https://pdfbox.apache.org/2.0/dependencies.html#minimum-requ...
So, for others out there that find this: just because you're using `PDFBox` does not necessarily mean that you are also using `log4j`, and therefore likely vulnerable to this latest issue.
I suspected something like this was afoot when I was reading through the manifest files. I don't get paid to write Java, so I wasn't sure if there was some other fantastical edge case that could cause an optional dependency to get loaded dynamically for whatever reason (I certainly couldn't have predicted this log4j fun).
Regardless, we are still going to have to remove this because our customers are now on a warpath. Reasonable arguments and nuanced proposals are not going to be feasible for this one. For us, the situation has quickly evolved into "remove 100% of java dependencies from the solution stack". Our customers are super paranoid, but we can't really blame them this time. When the CTO of a bank can understand the exact mechanism that compromises their systems (because it is so trivial to pull off), things are a lot more painful to negotiate.
I could see us adding support for grouping via the "metadata" that would inform the nav bar on how to group and accordion / collapse things. There already is a pattern for grouping in the library that is exemplified in the Query and Mutation carats
Thanks for the comment!
We added a lot of things that came to mind while trying to get our docs dialed in ourselves. Glad to see that others were looking for these same enhancements!
Thanks for the kind words! I wrote most of the enhancements and thought the static and dynamic example support was crucial to have.
Our schema is not as big as yours, but I could see how things could get a bit unwieldy on the navbar. Come on over to the repo and we can work on a solution together - I'm sure there's something we can figure out if we put on our design + product + engineer hats.
- The Maven entry for `PDFBox` does not list `log4j` as a dependency. However `commons-logging` is a dependency, and `log4j` is listed as an optional dependency there. https://mvnrepository.com/artifact/org.apache.pdfbox/pdfbox/...
- The `PDFBox` documentation points out that `log4j` is not needed (though `commons-logging` is) and that logging will "fall back to the standard java.util.logging API included in the Java platform" https://pdfbox.apache.org/2.0/dependencies.html#minimum-requ...
- That exploit PoC explicitly adds `log4j` as a dependency https://github.com/eelyvy/log4jshell-pdf/blob/main/pom.xml#L...
So, for others out there that find this: just because you're using `PDFBox` does not necessarily mean that you are also using `log4j`, and therefore likely vulnerable to this latest issue.