Activity for PoDoFo
-
Utente Ausiliario posted a comment on ticket #140
I recognized this isn't the place for this issue and been trying to remove the ticked but can't find the way to remove it. Anyway, I did resolve the build problem.
-
error using podofo.a libraruy
-
coralrong posted a comment on ticket #139
I Fond this is similar to CVE-2021-30469, But my podofo version is 0.9.8(which was published in 2022). So I think this is a new bug.
-
podofoencrypt bug
-
Rizwan Mohammed posted a comment on ticket #138
Attachment2
-
Cannot retrieve JS node with GetJavaScriptNode(true)
-
Mattia Rizzolo posted a comment on ticket #48
For cross-reference, this has been assigned CVE-2020-18971
-
Dominik Seichter committed [r2063]
test commit
-
PoDoFo released /podofo/0.9.8/podofo-0.9.8.tar.gz
-
Release branching
-
Tagging release 0.9.8
-
Version bump to 0.9.8
-
zyx committed [r2059]
podofosign: Default to SHA512 and add argument to change the digest
-
Patch by Wolfgang Stoeggl: Fix -Wmemset-elt-size warnings
-
Patch by Wolfgang Stoeggl: Add missing guards to header files
-
Patch by Wolfgang Stoeggl: Silence unknown pragma warnings under MINGW
-
Patch by Mark Rogers: Check that /DecodeParams values are in range (CVE-2018-20797)
-
Patch by F.E.: Ignore "/Prev 0" in trailer
-
Add FontTest::testBig2Little() unit test
-
Revert the previous commit (r2051) - it causes stack overflow
-
Patch by Michal Sudolsky: Fix undefined behavior in PdfFontTTFSubset.cpp:Big2Little
-
Patch by Andreas Brzesowsky: Add support for revision 6 encryption (PDF1.7 extension 8, PDF 2.0)
-
Patch by Mark Rogers: Add tests for stack overflow infinite recursion for CVE-2018-8002, CVE-2021-30470, CVE-2021-30471, CVE-2020-18971
-
Patch by Mark Rogers: Refactored stack overflow recursion guard to fix CVE-2018-8002, CVE-2021-30470, CVE-2021-30471, CVE-2020-18971
-
Alexander Finger posted a comment on ticket #137
It's been resolved. Don't know how to close the ticket!
-
@domseichter Any idea how to call PdfEncodingFactory::FreeGlobalEncodingInstances() method and not trow an exception? No matter where i put this i get an exception.
-
A workaround the memory leak is to change: inline bool PdfSimpleEncoding::IsAutoDelete() const { return true; // false; } But that does not look like a fix. The remaining leaks must be addressed. Can any dev comment on this? How void PdfEncodingFactory::FreeGlobalEncodingInstances() should be called? @mabri @domseichter I will try to run the litePDF and see what leaks i can find there, but it seems no podofo sources available for that windows version. But i have some tools that can be usefull to...
-
A workaround the memory leak is to change: inline bool PdfSimpleEncoding::IsAutoDelete() const { return true; // false; } But that does not look a fix. The remaining leaks must be addressed. Can any dev comment on this? How void PdfEncodingFactory::FreeGlobalEncodingInstances() should be called? @mabri @domseichter I will try to run the litePDF and see what leaks i can find there, but it seems no podofo sources available for that windows version. But i have some tools that can be usefull to detect...
-
Sample code to reproduce the memory leak. Please, ignore the openssl leaks. https://gist.github.com/avafinger/d2e2007d3ed87c452fa0c0b184dd11fa Build with: g++ sign.cpp -o sign -I/usr/include/openssl -lssl -lpodofo -lcrypto Run: ./sign pdf_to_sign.pdf certificate.pfx privatekey_password ==9319== ==9319== 40 bytes in 1 blocks are still reachable in loss record 1 of 6 ==9319== at 0x4C3217F: operator new(unsigned long) (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) ==9319== by 0x27221B: PoDoFo::PdfSimpleEncoding::PdfSimpleEncoding(PoDoFo::PdfName...
-
Did some cleanup for a better example... ==12668== Memcheck, a memory error detector ==12668== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al. ==12668== Using Valgrind-3.13.0 and LibVEX; rerun with -h for copyright info ==12668== Command: ./sign pdf_to_sign.pdf certificate.pfx @pwd@ ==12668== init ok p7Buf filled==12668== ==12668== HEAP SUMMARY: ==12668== in use at exit: 65,904 bytes in 5 blocks ==12668== total heap usage: 4,668 allocs, 4,663 frees, 801,911 bytes allocated ==12668==...
-
Did some cleanup for a better example... ==12668== Memcheck, a memory error detector ==12668== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al. ==12668== Using Valgrind-3.13.0 and LibVEX; rerun with -h for copyright info ==12668== Command: ./sign pdf_to_sign.pdf certificate.pfx @digital32@ ==12668== init ok p7Buf filled==12668== ==12668== HEAP SUMMARY: ==12668== in use at exit: 65,904 bytes in 5 blocks ==12668== total heap usage: 4,668 allocs, 4,663 frees, 801,911 bytes allocated ==12668==...
-
Sample code to reproduce the memory leak. Please, ignore the openssl leaks. https://gist.github.com/avafinger/d2e2007d3ed87c452fa0c0b184dd11fa Build with: g++ sign.cpp -o sign -I/usr/include/openssl -lssl -lpodofo -lcrypto Run: ./sign pdf_to_sign.pdf certificate.pfx privatekey.pkey ==9319== ==9319== 40 bytes in 1 blocks are still reachable in loss record 1 of 6 ==9319== at 0x4C3217F: operator new(unsigned long) (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) ==9319== by 0x27221B: PoDoFo::PdfSimpleEncoding::PdfSimpleEncoding(PoDoFo::PdfName...
-
Sample code to reproduce the memory leak. Please, ignore the openssl leaks. https://gist.github.com/avafinger/d2e2007d3ed87c452fa0c0b184dd11fa Build with: g++ sign.cpp -o sign -I/usr/include/openssl -lssl -lpodofo -lcrypto Run: ./sign pdf_to_sign.pdf certificate.pfx privatekey.pkey ==8335== 65,536 bytes in 1 blocks are still reachable in loss record 74 of 74 ==8335== at 0x4C33B25: calloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) ==8335== by 0x27AC53: PoDoFo::podofo_calloc(unsigned...
-
There is another leak in: const PdfEncoding* PdfEncodingFactory::GlobalWinAnsiEncodingInstance() { if(!s_pWinAnsiEncoding) // First check { Util::PdfMutexWrapper wrapper( PdfEncodingFactory::s_mutex ); if(!s_pWinAnsiEncoding) // Double check s_pWinAnsiEncoding = new PdfWinAnsiEncoding(); } return s_pWinAnsiEncoding; } Report ==3513== 144 bytes in 1 blocks are still reachable in loss record 3 of 5 ==3513== at 0x4C3217F: operator new(unsigned long) (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)...
-
PoDoFo Memory Leaks
-
Patch by Michal Sudolsky: Fix an undefined behavior in Big2Little()
-
Michal posted a comment on ticket #136
patch
-
UB in Big2Little
-
Patch by Federico Kircheis: Let the PdfSignOutputDevice::AdjustByteRange() return the resulting array
-
Christopher Creutzig posted a comment on ticket #25
As proposed, moved PdfRecursionGuard to broader visibility (we could argue about the right header for it, but that can be changed) and used it in PdfOutlineItem. This also fixes #48 (where I started, hence the patch's file name).
-
The problem with this file is a recursive outline structure, leading to infinite recursion in the PdfOutlineItem constructor: Following the /Next chain from 16 0 obj gets us to 19 0 R, 21 0 R, 20 0 R, back to 16 0 R. That is probably invalid (the pdf spec does not seem to explicitly say so, but it implies the chain of /Next should terminate), but the PdfOutlineItem constructor for 20 0 R doesn't know that alleged next entry already came earlier. Issue #25 is the same problem with /First entries a...
-
Default glyph widths should be scaled, too
-
Igor Mironchik created ticket #134
DPI in PdfImage
-
Invalid font spec found, causing PoDoFo error
-
Okay, that's pity. I'll commit this anyway, we'll see whether it'll break anything to anyone (I guess it will not). I think PoDoFo could generate files with missing Widths key, but I do not recall any detail, maybe I just mixed things up. In any case, it's committed as [r2045].
-
Patch by Christopher Creutzig: PdfFontFactory: Ignore FontDescriptor when without Widths/FirstChar/LastChar
-
Fonts with difference encoding can have ToUnicode, as well
-
Thanks for the file. I checked the PDF ISO and according to the "9.10.2 Mapping Character Codes to Unicode Values" the toUnicode has a precedence over the differences. Your patch does both, but I think in a good way. I committed your patch (slightly modified) as [r2044].
-
Patch by Christopher Creutzig: Prefer toUnicode within PdfDifferenceEncoding
-
The attached file should extract text like “Wear proper.” Without the patch, I am getting random-looking character substitutions, text like “Wlaeba cr lpot.” GetUnicodeValue should be able to handle requests for glyhs not in m_toUnicode, which includes it being empty. When there are both differences and toUnicode, I expect toUnicode to take precedence, yes.
-
Unfortunately, I do not have access to this publicly visible file any more, either. The file we have locally with the same problem is not something we can share publicly.
-
PdfSimpleEncoding::ConvertToUnicode must be able to return embedded NUL
-
Thanks for a quick response, I can reproduce it with it too. The patch doesn't apply, but I see where it is supposed to go (the diff -up helps with that too - there are some articles how to do it with svn), thus I applied it manually (attached patches are better, as you might notice from my comments on various other tickets, though I'm not sure why copy&paste did not work this time), and it works as expected, thus I committed it as [r2043]. Thanks again.
-
Patch by Christopher Creutzig: Make it possible to return embedded NUL from PdfEncoding
-
Patch by Chris: podofoimpose: Properly copy 'number' and 'null' objects
-
Patch by Christopher Creutzig: PdfXRefStreamParserObject: Correct 'indeces' typos
-
Allow querying the type of password used
-
Thanks for the patch. Attach them the next time, please. Otherwise I think it looks good, thus I committed it as [r2040] with a tiny change, I replaced was with is in the comment summary.
-
Patch by Christopher Creutzig: Introduce PdfEncrypt::IsOwnerPasswordSet()
-
Bug when drawing text using truetype font with difference encoding loaded from pdf
-
Thanks for the patch. I committed it as [r2039].
-
Patch by Michal Sudolsky: Fix bug when drawing text using truetype font with difference encoding loaded from pdf
-
String width is incorrect when using font loaded from pdf
-
This had been committed recently as [r2035], thus I'm closing it. See the thread referenced in the previous message.
-
memory leakage at src/base/PdfTokenizer.cpp:334 in IsNextToken(const char*)
-
Could you provide a test for this, please? I do not see the memory leak, neither your change makes any sense to me, because: a) it's an unrelated code to the Tokenizer; b) each Load() calls this->Clear() first and the PdfParser destructor calls the this->Clear() as well, thus the problem you fixed (and committed) has been probably just hiding another issue. I can be wrong, which is the reason why I ask for the test case. Considering how old this ticket is and the fact the code is changed, I'm closing...
-
excessive memory allocation crash at src/doc/PdfPagesTreeCache.cpp:45 when nInitialSize=0xffffffff
-
Thanks for the patch. I committed it as [r2038], though a bit better would be to limit the size and preallocate only the limited number, than nothing, but I used your version as is.
-
Patch by Christopher Creutzig: CVE-2019-10723 - Excessive memory allocation crash at PdfPagesTreeCache
-
CVE-2018-12983 - stack-based buffer over-read in the PdfEncryptMD5Base::ComputeEncryptionKey()
-
I gave a try to this patch and it does fix the problem. I did not notice any regression, thus I committed it as r2037. Thank you.
-
Fix by Matthew Brincke: CVE-2018-12983 - stack-based buffer over-read in the PdfEncryptMD5Base::ComputeEncryptionKey()
-
EncryptTest: Fallback to Helvetica font, when Arial cannot be loaded
-
podofo 0.9.6 NULL pointer dereference caused in `ImageExtractor::ExtractImage(PdfObject*, bool)`
-
Thanks fro the patch. It has got obsolete meanwhile, the current r2035 doesn't dereference the NULL pointer, it ends with an error: <</Type/XRef/Filter/FlateDecode/ID[<334A7E79C9FCCBC7E87D7C325FA995C4><334A7E79C9FCCBC7E87D7C325FA995C4>]/Index[ 0 256]/Info 2 0 R/Length 451/Root 1 0 R/Size 256/W[ 1 2 1]>> Error: An error 2 ocurred during processing the pdf file. PoDoFo encountered an error. Error: 2 ePdfError_InvalidHandle Error Description: A NULL handle was passed, but initialized data was expected....
-
Attached my local copy of the file. The NUL characters stem from the decoding table of the font.
-
Thanks for the patch. The PDF file is gone, unfortunately, thus I cannot test it. As I mentioned elsewhere, attaching patches it better. The change itself looks odd, because the snippet you pasted above does not contain a zero - maybe only because it's taken out of the context? Aka the text encoding changes the values?
-
I'm sorry, but I hate to open random sites whit their cookies consents and whatever. Would it be possible to attach such file and claim what precisely is your patch fixing, please? Like: without it, PoDoFo cannot.... , but with it PoDoFo can..... PdfObject* pToUnicode = nullptr); Use NULL instead, please, the same as the other code in the PoDoFo. if( m_differences.Contains( static_cast<int>(pszInput[i]), name, value ) ) pszUtf16[i] = value; if(m_bToUnicodeIsLoaded) { value = GetUnicodeValue(pszInput[i]);...
-
Thanks for the patch, just, the next time attach it. It avoids issues with whitespace and other things the web browser may break. Being it attached it is also significantly easier, and fool proof, when applying it. Unfortunately, I cannot test this because >this file< link above results in "Bad Request". It's safer to attach things to the bug trackers.
-
Patch by Michal Sudolsky: Correct string width when using font loaded from pdf
-
Patch by Christopher Creutzig: Correct typos in code comments
-
Given the offending instruction is just preallocating memory for performance, I believe this should be easy to fix, using an arbitrary limit for preallocation: Index: src/podofo/doc/PdfPagesTreeCache.cpp =================================================================== --- src/podofo/doc/PdfPagesTreeCache.cpp (revision 2033) +++ src/podofo/doc/PdfPagesTreeCache.cpp (working copy) @@ -42,7 +42,9 @@ PdfPagesTreeCache::PdfPagesTreeCache( int nInitialSize ) { - m_deqPageObjs.resize( nInitialSize );...
-
Matthew Brincke posted a comment on ticket #119
The PoC as output file of my program posted as source code in the previous comment is attached here.
-
I've removed the attachment to my previous because it was erroneous, I'm sorry. Attached to this post is a corrected and tested version (for creation of a PoC of this issue which I've checked to display correctly with different non-PoDoFo programs). The output PDF will be attached to my next post here. I haven't yet reproduced this issue with it, I don't have the right environment handy right now and need to go on a journey to my new workplace very soon. It might only work on unix-like OSes because...
-
I've removed the attachment to my previous because it was erroneous, I'm sorry. Attached to this post is a corrected and tested version (for creation of a PoC of this issue which I've checked to display correctly with different non-PoDoFo programs). The output PDF will be attached to my next post here. I haven't yet reproduced this issue with it, I don't have the right environment handy right now and need to go on a journey to my new workplace very soon.
-
I'm sorry I only implemented the latter program to produce a PoC PDF with the one-bit-per-pixel PNG as input (for the latter see above, was below when composing this, earlier replies) today and couldn't test it yet, I need to go to bed now as I'll have an important appointment tomorrow early in the morning. The C++ source code of the program is attached here. It takes the PNG file as input on standard input. If you use Windows, please insert a call switching that to binary mode into the source before...
-
I'm sorry I only implemented the latter program to produce a PoC PDF with the one-bit-per-pixel PNG as input (for the latter see above, was below when composing this, earlier replies) today and couldn't test it yet, I need to go to bed now as I'll have an important appointment tomorrow early in the morning. The C++ source code of the program is attached here.
-
I'm sorry I only implemented the latter program to produce a PoC PDF with the one-bit-per-pixel PNG as input (for the latter see below earlier replies) today and couldn't test it yet, I need to go to bed now as I'll have an important appointment tomorrow early in the morning. The C++ source code of the program is attached here.
-
The output PNG file of the program creating a one-bit-per-pixel Paeth-filtered PNG image is attached (it's a QR code of 21x21 pixels).
-
I'm sorry I didn't attach the program earlier, it's from April 8, 2021. The output file of can only be attached to the next reply.
-
This is CVE-2021-30472
-
This is CVE-2021-30471
-
This is CVE-2021-30470
-
For cross-reference, to this issue has been assigned CVE-2021-30469
-
Ivan Romanov posted a comment on ticket #102
Also you can use podofobrowser to see what exactly add your tool. In this case you will PDF file as a tree of nodes. But in this case you need to read PDF Reference to understand what you see.
-
I don't add watermarks. I only remove them. I use this tool to remove watermark from old Shimano bike components manuals. I don't know how they create such pdfs. Anyway I believe there are numbers of various ways to add watermarks. In worst case they won't be distinguish from regular text or images.
-
Ricky Wei posted a comment on ticket #102
Hi, thank you for provide such good things. By the way, I want to know how do you add watermark for the pdf? (I draw text as watermark but it can not be removed by this tool). Thanks.
-
Hi, thank you for provide such good things. By the way, I want to know how do you add watermark for the pdf? (I draw text as watermark but it can not be removed by this tool). Thanks.
-
Invalid font spec found, causing PoDoFo error
-
I've started with the implementation of a program to create a one-bit-per-pixel PNG with PNG_FILTER_VALUE_PAETH (only) and one to put that into a PDF w/o re-compression to remedy that there (still) isn't a proper PoC provided.
1 >