desktop-packages team mailing list archive

[Markus Kilås <digital@xxxxxxxxxxxxxx>]

(In reply to Albert Astals Cid from comment #102)
> So we're stuck on "need to use the offset" part, right?
> 
> Could someone try to do make the code use it even if we don't have any pdf
> that needs it?

I am not sure if it is good to apply the robustness principle on
security functions. In those cases it might be better to be defensive
and reject signatures not following the recommendation.

In this case if the ByteRange does not cover the whole document there
could be parts of the document that can be modified without invalidating
the signature. Would it then be good to tell the user that the signature
has been validated and the document is not modified even though in fact
there are parts of the document for which we don't know?

-- 
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to poppler in Ubuntu.
https://bugs.launchpad.net/bugs/740506

Title:
  verify digital signatures

Status in Evince:
  Confirmed
Status in Poppler:
  Confirmed
Status in poppler package in Ubuntu:
  Triaged

Bug description:
  Binary package hint: evince

  This is a feature request to verify digital signatures.  I'm receiving more and more digitally signed PDF's and evince already acknowledges them with:
  Signature Not Verified
  Digitally signed by <signer>
  Date:  <time stamp>
  Reason: <reason>
  Location: <location>
  but it would be great if Evince would be integrated into the distro's ca-certificate infrastructure to verify these signatures.

To manage notifications about this bug go to:
https://bugs.launchpad.net/evince/+bug/740506/+subscriptions