<html> <head> <base href="https://bugs.freedesktop.org/"> </head> <body> <div> <a class="bz_bug_link bz_status_NEW " title="NEW - Sign PDF with digital signature" href="https://bugs.freedesktop.org/show_bug.cgi?id=99416#c17">Comment # 17</a> on <a class="bz_bug_link bz_status_NEW " title="NEW - Sign PDF with digital signature" href="https://bugs.freedesktop.org/show_bug.cgi?id=99416">bug 99416</a> from <a class="email" href="mailto:ajohnson@redneon.com" title="Adrian Johnson <ajohnson@redneon.com>"> Adrian Johnson</a> <pre>(In reply to Hans-Ulrich Jüttner from <a href="show_bug.cgi?id=99416#c16">comment #16</a>) > > FormWidgetSignature::prepareSignature is writing the entire PDF to memory. > > It would be better to write it to a temp file then search it on disk. I > > don't like the way you search the PDF file for matching strings. It could > > end up matching some random data in another stream. It would be better to > > get the offset of the dict object you want to search and start the search > > for there for up to some reasonable maximum. > > > > eg > > > > XRefEntry *entry = doc->getXRef()->getEntry(ref); > > Goffset objOffset = entry->offset; > > > > Also, don't search for %%EOF to get the file size. Use > > doc->getBaseStream()->getLength() or Gfseek(f, 0, SEEK_END), Gftell(). > > > > Ok, but is it guaranteed that this offset and the length of > doc->getBaseStream() > are always updated when some objects in the PDF have been changed? After saving the PDF, open the saved PDF in a new PDFDoc object. > > I don't fully understand what signDocument() and prepareSignature() are > > doing. Which means some comments would be helpful. It appears you are saving > > the PDF, computing the signature, updating the signature object, then saving > > the PDF again. This assumes that the second save will produce an identical > > file except for the updated signature. I'm not sure if we can assume this > > will always be true. > > > > As the user later wants to save the signed document for example with the > PDFConverter from the Qt5 interface, saving the document again has to produce > an identical byte stream. Otherwise the signature would no longer be valid. I don't really understand how this works. Do you mean save a copy just after we signed the document? Or save any PDF that already has a signature? If we want to save an identical copy with the signature preserved we should just copy the file. It will be a lot faster. It may work now but what happens if we decide to always update the ModDate each time the PDF is saved? > > My naive understanding is that we could just create a signature dict with a > > dummy signature and offsets (large enough for any size, XRef allows up to 10 > > digits), save the PDF, compute the signature, and overwrite the dummy > > signature and offsets in the disk file with the real signature. What am I > > missing? > > I was striving not to waste to much space for the signature. That's why I > calculated a signature with the user's certificate and a hash over an empty > string first to see how much space it will take. I had the problem that the > byte range object itself changed it's size in the byte stream when some > number > in it gets an additional digit. Therefore I recalculated the byte range and > after it the signature once again. May bee this can be avoided if some extra > bytes are added to the space reserved for the signature. A byte offset can not exceed 10 digits. Typically at least 6 digits will be used. I don't think it is worth trying to save a few bytes.</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are on the CC list for the bug.</li> <li>You are the assignee for the bug.</li> </ul> </body> </html>