Age | Commit message (Collapse) | Author |
|
I (tried to) keep these files consistent locally with astyle in the past,
switching to clang-format makes sure that the recent problem with introducing
inconsistencies in these files doesn't happen again.
(On the flip side, it's great to see that now others also touch this
PDF/pdfium code. :-) )
Change-Id: I6065eab77c584197a82fe48e7d3e81b445106efd
Reviewed-on: https://gerrit.libreoffice.org/51701
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
Tested-by: Jenkins <ci@libreoffice.org>
|
|
Change-Id: I2040315707674dc99a37aedb96ac61dca274c13a
Reviewed-on: https://gerrit.libreoffice.org/47348
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
Tested-by: Jenkins <ci@libreoffice.org>
|
|
Which means xmlsecurity can be again a module that has no public
headers.
Change-Id: I3d0b03680398f80196fac187263e770fd44ed0ed
Reviewed-on: https://gerrit.libreoffice.org/41966
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
Tested-by: Jenkins <ci@libreoffice.org>
|
|
Also use comphelper::Base64 and
DateTime::CreateFromUnixTime to avoid depending on sax.
Change-Id: If1853f8d9481c9caa0625a111707531bbc495f75
Reviewed-on: https://gerrit.libreoffice.org/39993
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Ashod Nakashian <ashnakash@gmail.com>
|
|
And a few other similar small cleanups.
Change-Id: I91c992f33f2166d1cf27cbc9def1b69965040658
Reviewed-on: https://gerrit.libreoffice.org/39928
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
|
|
Change-Id: Ic5e4dac2626474dd3d44ef5097522bc7e2207cd1
|
|
Change-Id: I0b478dfa25a54595ba0dcee1ca3ec0291ee94ef5
|
|
The PDF code in xmlsecurity served two purposes:
- a generic PDF tokenizer
- signature verification
The first purpose is useful to have in VCL, so the PDF export code can
use it as well when it comes to PDF image handling.
This commit just moves most of the PDF code to VCL, it does not touch
the PDF export code yet. With this, also the somewhat odd xmlsecurity
dependency of CppunitTest_vcl_pdfexport can be removed as well.
Change-Id: I6fe8294ed5c4aa4d79f4b2ddef80a4d1c9d566cc
Reviewed-on: https://gerrit.libreoffice.org/35513
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
Tested-by: Jenkins <ci@libreoffice.org>
|
|
Signature verification code depends on sax and xmloff, but the rest of
the PDF tokenizer could be otherwise moved down to lower layers without
problems.
Change-Id: Ieca57279e9517935821c1d34f217fd10548035ef
Reviewed-on: https://gerrit.libreoffice.org/35512
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
Tested-by: Jenkins <ci@libreoffice.org>
|
|
If the first ReadChar fails due to EOF, ch would be used uninitialized. If the
second ReadChar fails due to EOF, the SeekRel(-1) shouldn't be executed.
Change-Id: Ibf99539a3a8880a77653bd7576721104f9782e36
Reviewed-on: https://gerrit.libreoffice.org/35504
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
|
|
Change-Id: Ie56c0c0e1917f159957babca346f1a3fa04bc629
Reviewed-on: https://gerrit.libreoffice.org/35253
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
Tested-by: Jenkins <ci@libreoffice.org>
|
|
Fails with commit 4ad249af88d15f2c8a09f0721a59d82718fcc201 (tdf#105093
sd PDF export: handle embedded videos, 2017-01-04) reverted.
Change-Id: I413ec9a5da3c0783541dcd28fb9a62dd896f955b
Reviewed-on: https://gerrit.libreoffice.org/34681
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
Tested-by: Jenkins <ci@libreoffice.org>
|
|
This is triggered by an upcoming unit test for tdf#105093.
Change-Id: I3c8e8662fcadaea1f6e19bf6194d8159916f368b
Reviewed-on: https://gerrit.libreoffice.org/34678
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
Tested-by: Jenkins <ci@libreoffice.org>
|
|
Fails with commit ee32c7d8083ae1449d6b379034be92995c142da9 (tdf#105461
PDF export: handle text fill color, 2017-02-01) reverted.
Change-Id: I3628a16d0810e3be3fb352340d06cdba472dcd3f
Reviewed-on: https://gerrit.libreoffice.org/34621
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
Tested-by: Jenkins <ci@libreoffice.org>
|
|
Invoke the PDF export filter and then use the PDF tokenizer from
xmlsecurity to assert the contents of created PDF file. The testcase
fails with commit 6db0f1feb1d9931d2726dd11a889c58815710ce0 (tdf#106059
PDF export: create a reference XObject for PDF images, 2017-02-22)
reverted.
Change-Id: I90526fef41d9560ae447f586df766bc50a491c43
Reviewed-on: https://gerrit.libreoffice.org/34609
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
Tested-by: Jenkins <ci@libreoffice.org>
|
|
Usually this is not a problem, but it's easy to construct a document
manually that contains multiple startxref tokens at the last 1024 bytes.
Make sure we read the last of those, not the first one.
This is triggered by an upcoming unit test for tdf#106059.
Change-Id: I94fbb5d407c4a03b7c2c6e207200127bb374e750
Reviewed-on: https://gerrit.libreoffice.org/34607
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
Tested-by: Jenkins <ci@libreoffice.org>
|
|
Change-Id: Ife06c74e1665273350b497a1a584d7f76297c13d
|
|
Change-Id: Id713460036331fd9f98fd1eca85ca61f57cf5afe
Reviewed-on: https://gerrit.libreoffice.org/33779
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
Tested-by: Jenkins <ci@libreoffice.org>
|
|
This was the last unit test that was disabled on Windows due to missing
implementation.
Change-Id: Ia7d84f72bcdf79267c7de17cd8822ed02c378642
Reviewed-on: https://gerrit.libreoffice.org/31552
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
Tested-by: Jenkins <ci@libreoffice.org>
|
|
Happened when the doc was smaller than 1024 bytes.
Change-Id: Ie5eea5905a09722e7958495d26e6c78ee234d3ba
Reviewed-on: https://gerrit.libreoffice.org/31500
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
|
|
From a comment's point of view, EOF is just a terminator, similar to \r
or \n.
Change-Id: I120bf1e75f1eb81a550af643051e6fc472873eff
Reviewed-on: https://gerrit.libreoffice.org/31499
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
|
|
Also fix parsing '<< /Foo [ /Bar ] >>'.
Change-Id: I3375001730b4d2e447b0dd8a7809a7bfb013126c
Reviewed-on: https://gerrit.libreoffice.org/31498
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
|
|
Map it to the partially signed (not all streams) ODF concept instead.
Change-Id: I7fc931e622b9f10a1261cd475b01a2f038e37ece
Reviewed-on: https://gerrit.libreoffice.org/31497
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
|
|
This caused not finding the length of a stream -> could not actually
verify signature.
Change-Id: I696b6da49525eb53f7575c27f619d2116be51f1d
Reviewed-on: https://gerrit.libreoffice.org/31490
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
Tested-by: Jenkins <ci@libreoffice.org>
|
|
If we skip to the first NL, then we start tokenizing some XML as PDF
data and soon error out due to an unexpected keyword.
Change-Id: I86b540a014e5a92ea4376ed765385a2ee568a3c1
Reviewed-on: https://gerrit.libreoffice.org/31472
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
|
|
This is broken, but work it around to avoid an infinite loop.
Change-Id: I132a3c19cfe53e6166bfc1a881d1bfa5071f85d4
Reviewed-on: https://gerrit.libreoffice.org/31471
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
|
|
And a couple of other changes to accept the bugdoc from
<https://github.com/esig/dss/
dss-pades/target/test-classes/plugtest/esig2014/ESIG-PAdES/RO/Signature-P-RO-4.pdf>.
Change-Id: I0fca9ba0bfe927ef91ae2592a5026b05d19879fd
Reviewed-on: https://gerrit.libreoffice.org/31462
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
Tested-by: Jenkins <ci@libreoffice.org>
|
|
This is a required part of the PAdES spec, but so far we only wrote it.
As a start just expose if the attribute exists or not.
Change-Id: Iae3815f764973a2fd29d72593236c2f484172101
Reviewed-on: https://gerrit.libreoffice.org/31436
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
Tested-by: Jenkins <ci@libreoffice.org>
|
|
The NSS code earlier started to save the hash algo ID of the signature
into the signature structure and I also added a unit test for this. This
failed on Windows when the system had at least one signing certificate
installed, as the mscrypto part of the patch was missing.
Change-Id: Ib09e9e53292b5beb011c96ecf6f51a5ee10c15b0
Reviewed-on: https://gerrit.libreoffice.org/31323
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
Tested-by: Jenkins <ci@libreoffice.org>
|
|
Assert the two user-visible changes: SHA-256 hashes and the SubFilter of the
signature.
Change-Id: I12a2355e2ddfc368bed4430a7b5ad244b5778afe
Reviewed-on: https://gerrit.libreoffice.org/31173
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
|
|
We can now write that on Windows as well when requested, after the
signing-certificate attribute is implemented using mscrypto.
With this, the PAdES validator at
<http://signatures-conformance-checker.etsi.org/protected/upload.php?sigtype=padesconf>
finds our Windows signature valid.
Change-Id: Iaeb4c36a1eac14e3d3c3c12d9cfd9529e7663f77
Reviewed-on: https://gerrit.libreoffice.org/31162
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
Tested-by: Jenkins <ci@libreoffice.org>
|
|
Equivalent of the earlier NSS commit, payload is just an empty sequence
at the moment.
Change-Id: I4639e2514ef01d23da04aedc30f63f9e8878223b
Reviewed-on: https://gerrit.libreoffice.org/31108
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
Tested-by: Jenkins <ci@libreoffice.org>
|
|
Also:
- avoid writing ETSI.CAdES.detached for now on Windows till doing so
results in an invalid signature in Acrobat
- extend the SEC_OID_PKCS1_SHA1_WITH_RSA_ENCRYPTION hack to do the same
for SHA256 and SHA512 as well, as Acrobat and NSS accepts such
signatures
Change-Id: Ibb0a204504b29230dd712ffb709d2037c1007218
|
|
That's where the implementation of such internal test binaries usually
are.
Change-Id: Ib7d2eb95de96d0d82e90e51f58da3a0c15a2ec71
Reviewed-on: https://gerrit.libreoffice.org/31073
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
|
|
Page 21 of "PAdES baseline signatures" specification from
<http://www.etsi.org/deliver/etsi_en/319100_319199/31914201/01.01.01_60/en_31914201v010101p.pdf>
says:
"The Signature Dictionary shall contain a value of ETSI.CAdES.detached
for the key SubFilter."
So in case the UI has the adescompliant checkbox enabled, write that
value instead of the Adobe default.
Change-Id: I69e606a32fb09bebd5e9b25b32150d1b8672f544
|
|
Change-Id: Ie6713d1bdf0010e5bc0bb70ca995c4dd36408673
|
|
Hopefully it's easier to read this way.
Change-Id: I145e00f8e57e20f2663d1c9ee494af5d93c014c7
|
|
This was the last problem to be able to counter-sign Acrobat-created PDF
1.6 signatures unlimited number of times.
Change-Id: I24ab80c8516b6fe9c08d57c08907bec70384dc28
Reviewed-on: https://gerrit.libreoffice.org/30757
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
|
|
The problem: an object stream provies obj#1 and obj#2, then an
incremental updates provides an updated obj#1'. Then we look up obj#2,
parse the stored objects on-demand, so at the end when later we look up
the first object, we find obj#1, not obj#1'.
An easy workaround would be to never update already existing objects
from object streams, but that would break when an incremental update
provides an object stream.
Fix the problem by parsing stored objects right after tokenizing the
object stream, and not later, on-demand, when we no longer have the
context what objects should be ignored.
This is needed (but not enough) to correctly append a signature at the
end of a PDF file that has both object streams and incremental updates.
Change-Id: I3c1fae5ac26804c8e8cc1984511f43cfa881c97b
|
|
This is especially needed, as we don't bother compressing updated
objects into sections on signing, we simply use a separate section for
each updated object.
Work towards supporting xref streams and incremental updates at the same
time.
Change-Id: Ie9759edbba816991615fafc6602cdd440141b989
|
|
With this our xref stream output is close enough to Acrobat so that the
existing signature verifier runs without any problems.
Change-Id: I6eca7966890365759c269b465e4bf4d86d335219
|
|
This way it's a bit smaller for large files and our output is closer to
what Acrobat produces.
Change-Id: Ide5f7b58a74a9d6ad7d806814eb57cb6931023cc
Reviewed-on: https://gerrit.libreoffice.org/30726
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
|
|
So that when we have a single signature with ID="Signature2", then we
use "Signature3" for the next ID, not "Signature2". (Acrobat uses that ID
for the first signature.)
Change-Id: I7032fbf014184da2a5be24730a92abc32a9a1258
Reviewed-on: https://gerrit.libreoffice.org/30725
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
|
|
In case the input document used a PDF 1.5 xref stream, not an old xref
table, then write that as part of the incremental update. Acrobat seems
to require this.
Change-Id: I9f1f73140c26308f8720aa1ffe1b905d0e60ede0
Reviewed-on: https://gerrit.libreoffice.org/30724
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
|
|
Normally it's a direct dictionary, but it's OK to have it as a reference, and
then the referenced object is a dictionary.
Change-Id: If09edaf23501883be68148e430c42e721ec68247
Reviewed-on: https://gerrit.libreoffice.org/30719
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
|
|
Normally it's a direct array, but it's OK to have it as a reference, and
then the referenced object is an array.
Change-Id: I191150632c2d8317ee6fd8c8169a90996298faa4
Reviewed-on: https://gerrit.libreoffice.org/30718
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
|
|
In case our xref table doesn't have an entry for "free" object types,
then the table size won't provide a valid id for a next object. That
resulted in creating all new objects with the same ID.
With this, our verifier at least can see the new signature when
appending one to a signed PDF 1.6 file.
Change-Id: Iac39a400706cfcd23dd814d2b81cb8b950c69fc6
Reviewed-on: https://gerrit.libreoffice.org/30704
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
|
|
Don't give up signing just because PDF 1.4 trailer is missing, provided
that PDF 1.5 xref stream is available.
Change-Id: I03360d428346537583a4398aa3a94b195b428713
Reviewed-on: https://gerrit.libreoffice.org/30703
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
|
|
This will need cross-reference stream write support, just don't crash
for now.
Change-Id: Id48c131b22d4ed96174693f3e96b14c273d596a8
Reviewed-on: https://gerrit.libreoffice.org/30702
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
|
|
Change-Id: I45d45513b102f4fdcb55e8de20b95b37f66ea463
Reviewed-on: https://gerrit.libreoffice.org/30658
Reviewed-by: Michael Stahl <mstahl@redhat.com>
Tested-by: Michael Stahl <mstahl@redhat.com>
|