(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 Ubuntu Touch seeded 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 -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
