Switch PDF dependency from iText to OpenPDF

[jonnermut]

iText 2.1.7 is affected by this security issue:
https://nvd.nist.gov/vuln/detail/CVE-2017-9096

OpenPDF is a LGPL/MPL fork of iText 2.1.7 which is maintained:
https://github.com/LibrePDF/OpenPDF

Seems to work fine with java melody, so it would be good if you could switch the dependency, and test with it going forward

[evernat]

First, as said here, "The attack can be carried out by submitting a malicious PDF to an iText application that parses XML data".
But you cannot submit malicious PDF to javamelody and javamelody never reads any PDF file. In fact, javamelody only creates PDF files (if you have the iText dependency in your application). So even if a part of iText has this vulnerability, there is nothing in javamelody which allows this vulnerability. So switching from iText to OpenPDF is a matter of being a good citizen and is not a matter of security of javamelody.

Second, if you use the javamelody-core dependency in your own application and if you have added the iText dependency in your application in order to have javamelody PDF reports, then it is up to you to add in your application the OpenPDF dependency instead of the iText dependency (OpenPDF is a one-for-one replacement of iText and seems to work fine as you said, but when doing that, be aware of requirements of OpenPDF on Java 8 and on versions of commons dependencies which may not be the same in your application). And perhaps the OpenPDF alternative could be in the official javamelody doc. That said, it's true that it is not so easy to switch dependencies if you use one of the ready-to-install javamelody plugins for Jenkins/Confluence/JIRA/etc which embeds iText.

Third, the OpenPDF requirements may conflict with the requirements of Jenkins/Confluence/JIRA/etc when using the javamelody plugins. For example, various versions of Jenkins may need dependencies on commons-io 2.4, commons-compress 1.10 and commons-codec 1.9 or other versions. And various versions of JIRA may need dependencies on commons-io 2.1, commons-compress 1.8.1 and commons-codec 1.9 or others. That will never be the same versions compared to the OpenPDF offical requirements and it may cause bugs in Jenkins/Confluence/JIRA/etc or in OpenPDF depending on which versions are used.

In summary, if you use javamelody-core and you want to use OpenPDF instead of iText, then no problem: it works as you said. But there is absolutely no way to exploit the vulnerability in the iText dependency by using javamelody, so it's not a matter of security anyway.

[jonnermut]

Fair enough, thanks for considering it.
In the real world my project was the subject of a security audit, which raised iText as a red flag. There’s no point explaining to a beuracratically minded auditor that a dependency of a dependency can’t actually be exploited: if there’s a CVE then there is a problem.
I raised this issue as, given I was forced to change, it would be better for my project if OpenPdf was part of the java melody build, so I have some more certainty when upgrading.
It gives you a path forward, where iText is a total dead end.

[evernat]

Yes, I suppose and I hope that OpenPDF will keep the iText 2.1.7 compatibility for a long time.
In any case, compatibility of javamelody with OpenPDF like with iText is something which I care about. Let us know if you have a bug with that.

[andreasrosdal]

Thanks for considering OpenPDF. I'm the maintainer. Please let me know if you have any issues.

@jonnermut Would you consider reopening this?

[jonnermut]

Sure, but it’s up to @evernat
@andreasrosdal is it part of the aim of openpdf to maintain compatibility with iText 2.1.7 indefinitely?
Or will it move to be something different?

[andreasrosdal]

is it part of the aim of openpdf to maintain compatibility with iText 2.1.7 indefinitely? Or will it move to be something different?

OpenPDF will maintain compatibility with iText indefinitely if possible. We will listen to the feeedback from the users of the library, so some changes could be made if the users wants or needs it.

[evernat]

related to issue 113 in OpenPDF

[andreasrosdal]

OpenPDF 1.2.5 has been released, where most of the dependencies have been removed.