[Poppler-bugs] [Bug 99416] Sign PDF with digital signature

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=99416

--- Comment #16 from Hans-Ulrich Jüttner <huj at froreich-bioscientia.de> ---
(In reply to Adrian Johnson from comment #15)
> +  char buf[24];
> +  time_t now = time(nullptr);
> +  size_t size = strftime(buf, 24, "D:%Y%m%d%H%M%S%z", localtime(&now));
> +  if (size >= 2 && size < 22)
> +  {
> +    // put timezone info into single quotes
> +    buf[size] = buf[size-1];
> +    buf[size-1] = buf[size-2];
> +    buf[size-2] = '\'';
> +    buf[++size] = '\'';
> +    buf[++size] = '\0';
> +    GooString gTime(buf, size);
> +    vObj.dictAdd(copyString("M"), Object(gTime.copy()));
> +  }
> 
> PDF date format uses a single quote to separate the time zone hour and
> minute, not enclose the minutes. strftime "%z" on windows returns the
> timezone name, not the offset.
> 
> We already have a time to PDF date function: DateInfo::timeToDateString().
> It doesn't currently add the timezone but I'll fix that that when I submit
> some win32 patches I am working on.
> 

That's fine, I didn't know about DateInfo::timeToDateString(). I'll use it
when you have fixed the timezone issue.

> 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?

> 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.

> 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.

-- 
You are receiving this mail because:
You are the assignee for the bug.
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/poppler-bugs/attachments/20170828/c4f2abfb/attachment.html>