Bug 496490 - Okular "corrupts" (QES-)signed documents
Summary: Okular "corrupts" (QES-)signed documents
Status: REPORTED
Alias: None
Product: okular
Classification: Applications
Component: PDF backend (show other bugs)
Version: 23.08.5
Platform: openSUSE Linux
: NOR normal
Target Milestone: ---
Assignee: Okular developers
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2024-11-20 12:00 UTC by MichaelOF
Modified: 2024-12-03 13:08 UTC (History)
1 user (show)

See Also:
Latest Commit:
Version Fixed In:
Sentry Crash Report:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description MichaelOF 2024-11-20 12:00:51 UTC
(Correctly) QES-signed pdf files are shown as "changed after signature" when opened in Okular. 
FYI: Adobe Acrobat Reader (rolling release, Win11) shows same files as "signature valid/correct"
Seems to be specific for some pdf of unknown (technical) source

STEPS TO REPRODUCE
1. Took (source) pdf from https://hapkido-muyedo.de/Anmeldung.shtml, concretely https://hapkido-muyedo.de/pdf/Aufnahmeantrag00.pdf
2. Filled, and signed with my "ID Austria" (Austrian eID) QES, via app "PDF-Over" (https://github.com/a-sit/PDF-Over)
3. Opened signed doc in Okular 

OBSERVED RESULT
4. Okular says in header "doc is digitally signed, changes since last signing"
-> Which is WRONG
5. Tested also with pdf https://hapkido-muyedo.de/pdf/Satzung00.pdf, which is a static pdf, no form data. Okluar also says "doc is digitally signed, changes since last signing"
6. Tested also with a pdf from totally different source: cups-pdf print of an email, signed, opened in Okular: Signature fine, no issue

Means IMHO, that buggy behaviour of Okular is related to these specific pdfs., Will try to find out with the creator what might be special, and add here later, if meaningful.

EXPECTED RESULT
QES-signed pdf files MUST NOT be changed by Okular WITHOUT user interaction, in any cases. 

SOFTWARE/OS VERSIONS
Linux/KDE Plasma: OpenSUSE Leap 15.6, all current patches 
KDE Plasma Version: 5.27.11
KDE Frameworks Version: 5.115.0
Qt Version: 5.15.12

ADDITIONAL INFORMATION

It's a "speciality" that pdf files with form data could be changed after signature anyway. But all pdf readers I'm aware are allowing this, but they 100% correctly shows the file as "changed" if changed, and "fine" if unchanged or changes reverted. 

Discussed all of the above with the maintainer of PDF-Over here: https://github.com/a-sit/PDF-Over/issues/128
He suspects a potential incorrect handling of "validation/auto-fill" rule by Okular here: https://github.com/a-sit/PDF-Over/issues/128#issuecomment-2485192603

Last Remark: If helpful, I of course could provide signed example pdfs if needed/helpful. But as I'm using an "anonymous" login for all my publicly visible internet activities, for good reasons, just attaching would NOT be an appropriate way, as the QES of course identifies me. So maybe there are other ways to share with you?
Comment 1 Sune Vuorela 2024-11-20 12:03:48 UTC
feel free to send to sune@kde.org
Comment 2 Sune Vuorela 2024-12-01 17:53:01 UTC
From a quick analysis.

Okular does not corrupt the document I analyzed. Poppler just think the signature is weird in part of the code. I still need to get a bit closer to why; I'm also a bit perplexed about having discovered a partial asn1 parser in the poppler code. Work still ongoing.
Comment 3 Sune Vuorela 2024-12-03 13:08:01 UTC
(In reply to Sune Vuorela from comment #2)
> From a quick analysis.
> 
> Okular does not corrupt the document I analyzed. Poppler just think the
> signature is weird in part of the code. I still need to get a bit closer to
> why; I'm also a bit perplexed about having discovered a partial asn1 parser
> in the poppler code. Work still ongoing.

I have to correct myself. I have started to wonder if PDF-Over is actually doing as expected.

The signature blob is, as I read the pdf spec, supposed to be a hex dump of a CMS object that is padded with '0' to fill the expected size.
It looks like on this file we have the CMS object that is padded with random stuff. The signature blob is at least suspiciosly 4096 bytes long. The CMS object itself 2111 bytes long according to the length encoding of the CMS object.

But I also only have two piece of data. It is a bit much to extrapolate from, but all the tools seems to agree.

Also if I replace the 'random stuff' with zeroes it validates.