Age | Commit message (Collapse) | Author |
|
Change-Id: I5f35c702ff9a613c6601cd0c3c42e9fc4f4e26a6
|
|
...as otherwise dynamic_cast<xmlsecurity::pdfio::PDFNameElement*>(...) in
xmlsecurity/qa/unit/pdfsigning/pdfsigning.cxx will fail at least on macOS,
causing CppunitTest_xmlsecurity_pdfsigning to fail.
Change-Id: I7c41c994a1e6145b4740a97ffe47d0c42c4e3ca0
|
|
Change-Id: Idb2e716cdc4933c2691de2df21a4ee7afda9e597
|
|
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>
|
|
Assert the two user-visible changes: SHA-256 hashes and the digest of
the signing certificate.
Change-Id: I0f931ef06f9bfc4be4eaa02a7530d57a414430c1
Reviewed-on: https://gerrit.libreoffice.org/31172
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
Tested-by: Jenkins <ci@libreoffice.org>
|
|
This makes this suite in sync with CppunitTest_xmlsecurity_pdfsigning. A
signing certificate is available on 64bit NSS platforms, as there we
provide a pre-created NSS db, but on other platforms by default there is
just no signing certificate. The certificate.crt I added earlier is not
enough, that's just the certificate, but it doesn't provide a private
key.
Change-Id: Ie09d70fc9bc7ab752382eef96659bedb414553f5
|
|
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>
|
|
Going via UNO for a class in the same module sounds like an overkill.
Change-Id: Iaa5b31d1b888c8d3f1c9b47ee787504191ce3d7d
Reviewed-on: https://gerrit.libreoffice.org/31148
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
Tested-by: Jenkins <ci@libreoffice.org>
|
|
That is what the default libxmlsec error handler
xmlSecMSCryptoErrorsDefaultCallback() does. Why show less information
in our own handler?
Change-Id: Ibc9f9b5066536d0f5cabbf2bda6d1fa14eca5613
|
|
Change-Id: I05450a0af00b200145312301207b8f6d3af05145
|
|
Change-Id: Ie18a1bd4c006a9c7a54dc79747cb7e300315640a
|
|
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
|
|
Change-Id: If26be2b51a1fd8a6ad3e96928e2d142d1ced2845
Reviewed-on: https://gerrit.libreoffice.org/31074
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
|
|
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>
|
|
Change-Id: I28bb2a33c02d8eadced584d3d3f2b62b2e847324
|
|
this is motivated by the new screenshot feature
the initial proposed solution involved running make screenshot once per lang
which took ~6 hours for --with-lang=ALL on tb68 a reasonnably big
windows slavebot.
with this patch, one can run make screenshot just once and get all the screenshot
the elapsed time is 36 inutes on the same box/same config a 10x improvement.
Change-Id: I4339caebf915c118aa455de2a7e56e1a4e413939
Reviewed-on: https://gerrit.libreoffice.org/30970
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Norbert Thiebaud <nthiebaud@gmail.com>
|
|
Change-Id: Iac3d2206388fde23d2f3d7a05b23978851cf2800
|
|
Change-Id: Ife64ab3683479baf152357a6167718f13c9b6089
Reviewed-on: https://gerrit.libreoffice.org/30964
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
Tested-by: Jenkins <ci@libreoffice.org>
|
|
Change-Id: I15a00a8c6f8c8e735694baa25e06ed4db0875d43
|
|
not randomly scattered through the code
found with something like:
git ls-files *.cpp | xargs grep -Pzl "(?s){.*#include"
Change-Id: I9c242fa4ef99e8677f2800d7ec9f16d16e488351
Reviewed-on: https://gerrit.libreoffice.org/30952
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@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: I90db6e3c69a6dc90ce1df0dbb5b9d7a81cd1bbea
|
|
And rename it to AdES, as the PDF PAdES generation will be affected by
this checkbox in the near future.
Change-Id: I06121e4eb9debac7a55a737a71780c2fa5c4d084
Reviewed-on: https://gerrit.libreoffice.org/30908
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
Tested-by: Tor Lillqvist <tml@collabora.com>
|
|
Change-Id: Ic7aa466c62eb8850d3c6b50c0e10b0575bd9b82e
|
|
Change-Id: Ic15c34c77ff24a506b59ed02db3cfbb6722d0f25
|
|
Change-Id: If5793cd8a721ac5b4fce5280b6180f2827c72501
|
|
Change-Id: I3e38b1d445c368c28e807202b94c603bd2b2c672
Reviewed-on: https://gerrit.libreoffice.org/30872
Reviewed-by: Samuel Mehrbrodt <Samuel.Mehrbrodt@cib.de>
Tested-by: Samuel Mehrbrodt <Samuel.Mehrbrodt@cib.de>
|
|
Change-Id: I8ed5242a4337da2ec1568d92bebfdad4915e6128
|
|
These files had a consistent style previously, keep them that way.
Change-Id: I6347efd4a301ddd758f4661778c0dfb68585940d
|
|
Change-Id: Ie6713d1bdf0010e5bc0bb70ca995c4dd36408673
|
|
Probably cid#1394297 was a fallout from that?
Change-Id: I98134ccbbbe8bc0b7d3c172ffddcdc3666f436f6
|
|
Change-Id: I64239dfcfbc2383c2bf53c0cb86196d3f2c79330
|
|
Hopefully it's easier to read this way.
Change-Id: I145e00f8e57e20f2663d1c9ee494af5d93c014c7
|
|
Accept and store a set of EncapsulatedX509Certificate data for a
signature.
Change-Id: Iae69502bc8caa0287c8f6d6c352256bdda22406b
|
|
Change-Id: I4302d0d767a1bf50fd34a78e9aa0ad6d6b0c7a22
|
|
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
|
|
Pass an XAdES flag to a couple more functions and adapt to that.
Factor out writeDigestMethod() and writeSignedProperties() from
OOXMLSecExporter::Impl to DocumentSignatureHelper and use them in an
additional place.
Write xd:UnsignedProperties with EncapsulatedX509Certificate. Probably
much more work needed.
Change-Id: I2a0cd1db6dd487b9c7ba256ad29473de3d271cd8
|
|
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
|
|
Change-Id: I8f2963c9b6b1c8717ea4d19453815fffa6e68484
|
|
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>
|
|
Sure, using a namespace means we have to decorate each function with the
XMLSECURITY_DLLPUBLIC, but who cares.
Change-Id: If9a364d1be9c5f4cd02f3f146e8b01bd608b373e
|
|
Change-Id: Id9daf4f5e3208eca8d3d845983b58ab056557621
|
|
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>
|