| Summary: | Strange checking for signing bounds | ||
|---|---|---|---|
| Product: | [Applications] okular | Reporter: | Oleg Solovyov <mcpain> |
| Component: | general | Assignee: | Okular developers <okular-devel> |
| Status: | ASSIGNED --- | ||
| Severity: | normal | CC: | aacid, nate, yurchor |
| Priority: | NOR | ||
| Version: | 20.12.3 | ||
| Target Milestone: | --- | ||
| Platform: | Other | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed In: | ||
| Sentry Crash Report: | |||
| Attachments: | signed PDF | ||
pdfsig is unrelated to okular. Please report this against poppler at https://gitlab.freedesktop.org/poppler/poppler/-/issues (In reply to Albert Astals Cid from comment #1) > pdfsig is unrelated to okular. Please report this against poppler at > https://gitlab.freedesktop.org/poppler/poppler/-/issues poppler behaviour is correct. In case I mentioned above, okular will treat [0 - 23225], [31227 - 167454] and [0 - 167454] as the same, which is incorrect. It's the okular bug. I really don't understand with "will treat [0 - 23225], [31227 - 167454] and [0 - 167454] as the same". Can you clarify? (In reply to Albert Astals Cid from comment #4) > I really don't understand with "will treat [0 - 23225], [31227 - 167454] and > [0 - 167454] as the same". > > Can you clarify? In the Document::requestSignedRevisionData(const Okular::SignatureInfo &info) { [...] const QList<qint64> byteRange = info.signedRangeBounds(); f.seek(byteRange.first()); QByteArray data; QDataStream stream(&data, QIODevice::WriteOnly); stream << f.read(byteRange.last() - byteRange.first()); f.close(); [...] } When byteRange == (0, 167454) the data from bytes 0-167454 will be returned. What will happen when byteRange == (0, 23225, 31227, 167454)? As far as I can see from code, the data from bytes 0-167454 will be returned. Or, speaking differently, the data from bytes 23226-31226 will be included to byte array we return instead of being skipped because they are not signed and poppler knows about it, formatting signed ranges in pairs for user. Okular for some reason behaves differently and grabs first and last item from byteRange in assumption that it contains the _one and only_ pair. I honestly don't see how that is a problem, the gap in the middle of ByteRange is the contents of the signature itself, so why does it matter whether that part is included or not when viewing what was signed? (In reply to Albert Astals Cid from comment #6) > I honestly don't see how that is a problem That definitely doesn't mean that there is no problem. Will this bug being fixed cause any problems? Or fixing this bug will be a problem itself? If answers are "no", I can apply the same "why this is a problem" logic. > so why does it matter whether that part is included or not when viewing what was signed? Documentation says: > Returns the part of document covered by the given signature @p info. In current implementation uncovered parts are returned when there are gaps. Hence, there is documentation/behavior mismatch. PS why you're asking such questions if you certain that there is no matter whether that part is included or not? ping! (In reply to Oleg Solovyov from comment #8) > ping! You can propose your patches here: https://invent.kde.org/graphics/okular A possibly relevant merge request was started @ https://invent.kde.org/graphics/okular/-/merge_requests/418 |
Created attachment 137267 [details] signed PDF SUMMARY As far as I can see in the code, only byteRange.last() and byteRange.first() are used. That's strange because of: $ pdfsig ul-1172651010388-20210402102439.pdf Internal Error (0): couldn't find default Firefox Folder Digital Signature Info of: ul-1172651010388-20210402102439.pdf [...] - Signed Ranges: [0 - 23225], [31227 - 167454] Signed Ranges becomes in pairs. Thus, when getting signed data, okular will treat the whole PDF file to be signed, which is not the case. I'm preparing a patch now, which will get this issue solved.