Set OpenPDF profile active by default in flying-saucer-pdf.

[ghost]

Set OpenPDF profile active by default in flying-saucer-pdf.

The iText profile specifies iText version 2.1.7, which is no longer maintained and vulnerable to CVE-2017-9096 iText XML External Entity Vulnerability.

[pbrant]

Thanks. Would there be a way to publish this as a separate artifact instead of changing the default? For a project already using (old) iText, it might be surprising if another JAR is pulled in.

[ghost]

I was really hoping to encourage people to upgrade from the old unmaintained iText 2.1.7 to a maintained and updated version of OpenPDF. So when the users of Flyingsaucer update to the latest version of Flyingsaucer, then they will also get the latest maintained and updated version of this dependency: which is currently OpenPDF.

OpenPDF has updated the versions of the libraries it depends upon, such as to the latest version of the Bouncy Castle Crypto APIs. There are also many bugfixes in the latest version of OpenPDF. Still, it is compatible.

Users who depend on the old iText version 2.1.7 can still build Flyingsaucer with the itext maven profile. However, that version of iText was released in 2009, so I really think that we should encourage users to update.

As one of the maintainers of OpenPDF, I hope that you will change the default to OpenPDF instead of keeping the very old version as default. This is a change to update to a maintained version of a dependency, which would be in the interest of most users of both libraries.

[ghost]

@pbrant How do you suggest this be solved? Any chance you would accept this change?

[pbrant]

Thanks for keeping after this. I'm very sorry for the late reply. I agree that OpenPDF is a better option than iText 2.1.7 going forward. My concern is that projects that have a separate dependency on iText will end up with both on the class path and depending on the situation it may be hit and miss which one actually gets used. I'd also rather not force users that want to use iText 2.1.7 to build (and more importantly, deploy) FS themselves. Also, FS sees a fairly large number of downloads, but both of the Google groups have a fairly small number of members. Hence, there isn't an effective way to communicate with the community of FS users as a whole. In short, for now, I'd be completely on board with releasing a separate flying-saucer-pdf-openpdf artifact and also encouraging users to use that version, but I'd rather not change flying-saucer-pdf for now. I'd suggest keeping the PR open though and revisit down the road. (I'll take a look at the Travis setup shortly. Thanks for that too.)

…

On Wed, Apr 5, 2017 at 7:29 AM, Andreas Røsdal ***@***.***> wrote: @pbrant <https://github.com/pbrant> How do you suggest this be solved? Any chance you would accept this change? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#123 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AABeaKG9_HQK2-iyqls2yDwePQwx1AUWks5rsybWgaJpZM4MgiA_> .

[ghost]

This seems like a good solution. Could you please make such a separate
flying-saucer-pdf-openpdf artifact release?

[ghost]

iText 2.1.7 is vulnerable to CVE-2017-9096 iText XML External Entity Vulnerability http://seclists.org/bugtraq/2017/Nov/20

I would recommend switching from iText 2.1.7 to OpenPDF 1.0.5, where this vulnerability is fixed.
https://github.com/LibrePDF/OpenPDF/releases/tag/1.0.5

[illumi]

My concern is that projects that have a separate dependency on iText will end up with both on the class path and depending on the situation it may be hit and miss which one actually gets used.

As one of those people, I'd welcome an update to use OpenPDF!

[asturio]

Maybe a separate artifact using openpdf could help people, switch to openpdf. We are also using itext now, and flyingsaucer in the company. If there is a flyingsaucer-openpdf build from maven central, we could also change itext to openpdf. Or else we need to work with lots of exclusions.

But I think you should keep 2 different artifact published.

Just my 2 ¢.

[ghost]

Great idea, @asturio. Perhaps you are the person capable of publishing the flyingsaucer-openpdf release to maven central?

[pbrant]

I'm absolutely not opposed to publishing two artifacts, but I'd need help with the pom.xml wrangling and it can't substantially complicate the publishing process. A separate mvn run with different parameters wouldn't be a problem though. In short (and I apologize if this is too direct), make this easy for me and it'll be done.

…

On Tue, Nov 21, 2017 at 8:39 PM, Andreas Røsdal ***@***.***> wrote: Great idea, @asturio <https://github.com/asturio>. Perhaps you are the person capable of publishing the flyingsaucer-openpdf release to maven central? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#123 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AABeaK6zXXahbDe6p0IX4tRGpKytlfRaks5s4ybwgaJpZM4MgiA_> .

[ghost]

Given that iText 2.1.7 has a known, unfixed security vulnerability, it could be argued that continuing to release it is unethical. In my opinion, iText 2.1.7 should be replaced by OpenPDF.

So accepting this pull-request, then updating the OpenPDF version to 1.0.5 in flying-saucer-pdf/pom.xml is all you have to do.

[asturio]

There are some possibilities. I think the best is, if the build are done by the project maintainer, alas @pbrant .

I suggest haven a separate branch here, with everything set to make *-openpdf artifacts. And the development beeing made on the master-branch. Every time a new release is released, the changes from master should also be merged in this fs-openpdf branch, and that branch released. And the only differences between the 2 branches should be, that one uses itext and the other openpdf. And of course the artifact names.

The other option should be to make this through maven profiles, but the tweaking of artifact names is not that straight forward.

I think the 1st. option will cope best and should be easier to implement, even in the CI-Environment.

@pbrant: Would be option 1 ok for you? I could prepare a branch, to be pulled in this new branch here (which should exist before I can create the pull request).

[pbrant]

Sounds good to me. I've pushed an openpdf branch.

…

On Fri, Nov 24, 2017 at 6:43 PM, asturio ***@***.***> wrote: There are some possibilities. I think the best is, if the build are done by the project maintainer, alas @pbrant <https://github.com/pbrant> . I suggest haven a separate branch here, with everything set to make *-openpdf artifacts. And the development beeing made on the master-branch. Every time a new release is released, the changes from master should also be merged in this fs-openpdf branch, and that branch released. And the only differences between the 2 branches should be, that one uses itext and the other openpdf. And of course the artifact names. The other option should be to make this through maven profiles, but the tweaking of artifact names is not that straight forward. I think the 1st. option will cope best and should be easier to implement, even in the CI-Environment. @pbrant <https://github.com/pbrant>: Would be option 1 ok for you? I could prepare a branch, to be pulled in this new branch here (which should exist before I can create the pull request). — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#123 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AABeaN18-yKUd4CLpbWWDNGuHONZyxkuks5s5wAngaJpZM4MgiA_> .

[ghost]

@asturio @pbrant Any news on this security issue in Flyingsaucer / iText 2.1.7?

[asturio]

Too much work at work :-). Doing this now.

[ghost]

<!-- https://mvnrepository.com/artifact/org.xhtmlrenderer/flying-saucer-pdf-openpdf -->
<dependency>
    <groupId>org.xhtmlrenderer</groupId>
    <artifactId>flying-saucer-pdf-openpdf</artifactId>
    <version>9.1.11</version>
</dependency>

https://mvnrepository.com/artifact/org.xhtmlrenderer/flying-saucer-pdf-openpdf/9.1.11

[Marco-Sulla]

I would contribute with a little modification. Where is the source code of flying-saucer-pdf-openpdf?

[pbrant]

It's on the openpdf branch. For releases, I merge master there and re-release just the -pdf artifact (which is renamed to -pdf-openpdf there). That seemed the most graceful way to handle the dependency change (but I'm open to suggestions too).

…

On Sun, Mar 18, 2018 at 12:56 PM, MarcoSulla ***@***.***> wrote: I would contribute with a little modification. Where is the source code of flying-saucer-pdf-openpdf? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#123 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AABeaDVGrSsR-ltQLt6X12OPKlHN-rNxks5tfktcgaJpZM4MgiA_> .

[ST-DDT]

It looks like there is no maven artifact for flying-saucer-pdf-openpdf:9.1.13 in the public repos yet.

[stephane-dereppe]

Could you merge the 9.1.13 tag to the openpdf branch and deploy it to maven central please?

[pbrant]

Hmm... I'll have to release this as 9.1.14. It looks like the sync with Maven Central only works the first time. I'll do this after work today, but in the meantime it is available here (and has been since May): https://dl.bintray.com/flyingsaucerproject/maven/org/xhtmlrenderer/flying-saucer-pdf-openpdf/9.1.13/

…

On Tue, Jun 19, 2018 at 8:47 AM Stéphane Dereppe ***@***.***> wrote: Could you merge the 9.1.13 tag to the openpdf branch and deploy it to maven central please? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#123 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AABeaHeDtOjm8gBIGMPhPrOw8PLr2xA3ks5t-J6FgaJpZM4MgiA_> .

[ghost]

@pbrant Can you please update to OpenPDF version 1.0.5 in flying-saucer-pdf-openpdf also?

[ghost]

I can't find flying-saucer-pdf-openpdf 9.1.14 here:
https://mvnrepository.com/artifact/org.xhtmlrenderer/flying-saucer-pdf-openpdf

Are you sure it has been published?

[ghost]

OpenPDF 1.1.0 has been released. https://github.com/LibrePDF/OpenPDF/releases/tag/1.1.0

Can you please update to use that in this project?

[ST-DDT]

9.1.14 is now in the maven repo.

[andreasrosdalw]

@pbrant Any news on setting OpenPDF as the default?
OpenPDF is the future, not the old iText 1.2.x version.

[GitMensch]

@pbrant with ccfadb6 this PR can be closed, can't it?

[andreasrosdalw]

This PR could be merged now, not closed. OpenPDF should be the default.

[benjohnde]

Any updates on this issue?

[asolntsev]

@benjohnde @andreasrosdal FYI I took over FlyingSaucer project maintenance. We can continue discussion here. I also think that switching to OpenPDF is a good idea.

[andreasrosdalw]

@asolntsev Congratulations! Will you please make OpenPDF the default PDF library for FlyingSaucer?

[asolntsev]

@andreasrosdal Yes, it's the plan. I just need some time to investigate the background, the release process etc.

[andreasrosdalw]

Further, my advice for making Flying Saucer a success in the future would be to add support for more modern HTML5 syntax, and not throwing exceptions if some HTML element is invalid.

[asolntsev]

@andreasrosdal Thank you for sharing your vision.

Yes, I believe it would be great, BUT who is going to implement it? I rather think I don't have enough resources to implement modern HTML5 syntax... Sounds like a huge work to do.

[andreasrosdalw]

Yes, I believe it would be great, BUT who is going to implement it?

There are two separate issues: the first is that Flying Saucer throws exceptions whenever it parses a nonvalid xhtml element, such as < br >, it needs the xhtml < br />. I wonder if this can be solved with some simple exception handling?

The other issue is full support for html5. Can it be done, by focusing on one element at a time, focusing on the most important elements first?

Maybe people on Github will create pull requests if there are specific tasks on Github for each task of full html5 support?

Also, cooperation and copying from
https://github.com/danfickle/openhtmltopdf

[andreasrosdalw]

There is also: https://github.com/imario42/openhtmltopdf

[pbrant]

We've used https://about.validator.nu/htmlparser/ at work for a long time to provide HTML5 syntax support. My assumption has been that a lot of folks do something similar when they embed FS in a larger application.

Supporting CSS Flexbox, Grid, etc. would indeed be quite a lot of work though.

[asolntsev]

@andreasrosdal @pbrant I would mention here: you strongly wish to use OpenPDF by default because you assuming it's newer or better supported?
But I see this assumption is false.

I submitted an important pull request to OpenPDF more than month ago:
LibrePDF/OpenPDF#955

Nobody has merged it. Nobody is even reacting to messages. Seems OpenPDF project is dead. :(

[asturio]

Sorry for that, I really have very small spare time for maintaining the project. Some PRs get merged only after many months. I'm the only maintainer, and there are times where I don't read messages or PRs for months. Your PR won't get into 1.3.31, but maybe in the next one. OpenPDF is not dead, maybe just a little dormant. Anyway better than using iText 2.1.7 from 2009. But never mind. I also thouth flyingsaucer was dead, as one of my PRs was also there for years, without beeing noticed. Am 31.10.23 um 23:15 schrieb Andrei Solntsev:

…

@andreasrosdal <https://github.com/andreasrosdal> @pbrant <https://github.com/pbrant> I would mention here: you strongly wish to use OpenPDF by default because you assuming it's newer or better supported? But I see this assumption is false. I submitted an important pull request to OpenPDF more than month ago: LibrePDF/OpenPDF#955 <LibrePDF/OpenPDF#955> Nobody has merged it. Nobody is even reacting to messages Seems OpenPDF project is dead. :( — Reply to this email directly, view it on GitHub <#123 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ADDN6CVRMTUE5AHMKYZV4KTYCFZ7TAVCNFSM4DECEA72U5DIOJSWCZC7NNSXTN2JONZXKZKDN5WW2ZLOOQ5TCNZYHAYTCMBVGEZA>. You are receiving this because you were mentioned.Message ID: ***@***.***>

[andreasrosdalw]

@asturio If you would like help maintaining OpenPDF, I can help with maintenance again. Please add me as a maintainer again and I can help with reviewing and merging PRs and making a new release.

[andreasrosdalw]

LibrePDF/OpenPDF#955 has been merged now. Hopefully we will create a new release of OpenPDF with this included very soon.

[asolntsev]

Sorry for that, I really have very small spare time for maintaining the project.

Please forgive me if my words sounded bad. I didn't want to blame anybody personally. We all need rest and do the open-source projects at spare time.

I just tried to estimate the project overall status.

NB! I believe all mature open-source project should have several maintainers who can merge pull requests and release new versions. Without it, any project sooner or later become a "forgotten child".
@asturio @andreasrosdal I highly recommend to take some actions in this direction.

[andreasrosdalw]

@asolntsev You are welcome to contribute to and help maintain OpenPDF also. Thank you.
In particular PDF/A support LibrePDF/OpenPDF#980, FIPS Compliance LibrePDF/OpenPDF#921, improving PNG loading speed LibrePDF/OpenPDF#596, and generally supporting new PDF standards, are some areas we need help.