pdftohtml is vulnerable to issues described in bug 114428
Given the risk of this specific exploitation path, I'd wait for more to come before releasing GLSA.
how about using poppler as the backend for pdftohtml? see Bug #115863 for more
Not sure it would help using poppler, since it's also xpdf-codebased AFAICT. What would help would be to RDEPEND on xpdf or poppler so that fixing them would also fix pdftohtml...
Back to ebuild, see bug #117481 for details.
Robbat2 any news on this one?
[23:24:56] <genstef> jaervosz: for pdftohtml, we still need to fix poppler so it can take over all the functionality
What is missing on poppler? I've added the pdf2xml.dtd.
dang: the DTD should be it. now we just need a good way to migrate existing pdftohtml to users to poppler.
Yep. For the record, poppler-0.5.0 (just released) has the utilities in it already, so upstream is with the program. I'm going to push the dtd patch to them.
(In reply to comment #8) > now we just need a good way to migrate existing pdftohtml to users to poppler. unless there is a smarter portage-way for this, we could package.mask pdftohtml as affected and say in the GLSA that users should migrate to poppler ? Let us know when a poppler replacement candidate in is portage
poppler can already replace pdftohtml, we just need to manage the conversion for users now.
Stefan what needs to be done to get this one out?
pdftohtml is now in p.mask, and will be removed early next week (keeping it around for a few days in case problems crop up). I've changed all deps in the tree (sys-cluster/charm and app-zope/portaltransforms for those keeping track) to point to poppler instead.
GLSA 200601-17