summaryrefslogtreecommitdiff
path: root/xmlsecurity/inc
AgeCommit message (Collapse)Author
2016-11-12cid#1394298: This field was uninitialized and unusedTor Lillqvist
Probably cid#1394297 was a fallout from that? Change-Id: I98134ccbbbe8bc0b7d3c172ffddcdc3666f436f6
2016-11-12More EncapsulatedX509Certificate workTor Lillqvist
Change-Id: I64239dfcfbc2383c2bf53c0cb86196d3f2c79330
2016-11-11xmlsecurity: extract parts of PDFDocument::Sign() into separate functionsMiklos Vajna
Hopefully it's easier to read this way. Change-Id: I145e00f8e57e20f2663d1c9ee494af5d93c014c7
2016-11-11More XAdES workTor Lillqvist
Accept and store a set of EncapsulatedX509Certificate data for a signature. Change-Id: Iae69502bc8caa0287c8f6d6c352256bdda22406b
2016-11-10More work in progress on XAdES compliant ODF signingTor Lillqvist
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
2016-11-09These functions don't even need to be XMLSECURITY_DLLPUBLICTor Lillqvist
Change-Id: I8f2963c9b6b1c8717ea4d19453815fffa6e68484
2016-11-09xmlsecurity PDF sign: improve suggested signature IDMiklos Vajna
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>
2016-11-09Don't use a class for what namespaces are forTor Lillqvist
Sure, using a namespace means we have to decorate each function with the XMLSECURITY_DLLPUBLIC, but who cares. Change-Id: If9a364d1be9c5f4cd02f3f146e8b01bd608b373e
2016-11-08xmlsecurity PDF verify: fix handling of xref stream free objectsMiklos Vajna
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>
2016-11-08xmlsecurity: move the sec context from the format helpers to the sign managerMiklos Vajna
The signature manager always creates an XML helper, and optionally creates a PDF helper as well. Both of them initialize xmlsec, and when the signature manager is deleted, there are two de-inits, leading to an assertion failure in xmlsec. Fix the problem by moving the duplicated xmlsec init to the signature manager. This has the additional benefit that general security-related code no longer has to talk to the XML helper, it can use the signature manager, which feels more natural. (What viewing a certificate had to do with XML?) Change-Id: If6a6bc433636445f3782849a367d4a7ac0be7688 Reviewed-on: https://gerrit.libreoffice.org/30695 Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk> Tested-by: Jenkins <ci@libreoffice.org>
2016-11-08Fallout from previous commit 248dbe1de5eeea9e9173e53a0b1891f63ff73d68Tor Lillqvist
Remove SignatureInformation::nSecurityEnvironmentIndex as it was always -1. Change-Id: I39247e5c40ce36e394c30b450626eca533f46267
2016-11-08Work in progress on supporting XAdES-compliant signatures for ODFTor Lillqvist
xmlsecurity is such a mess. Too many different classes that actually have more or less identical life-time, with names that smell of delusions of grandeur. "Manager", "security framework controller" etc for stuff that actually exist only during the execution of a simple dialog. And then a "helper" class that actually in on a higher level than a "framework controller". But oh well. Change-Id: I86e461b1bc91a0d8f5b7fb9f13a5be201729df1e
2016-11-07Fix typos (also in the code)Andrea Gelmini
Change-Id: I45d45513b102f4fdcb55e8de20b95b37f66ea463 Reviewed-on: https://gerrit.libreoffice.org/30658 Reviewed-by: Michael Stahl <mstahl@redhat.com> Tested-by: Michael Stahl <mstahl@redhat.com>
2016-11-04xmlsecurity PDF NSS verify: handle SHA1_WITH_RSAMiklos Vajna
SHA1_WITH_RSA is a signing algorithm, not a digest one, but let's accept it, so LO on Linux can verify a signature generated by LO on Windows. It's annoying that equivalent mapping in NSS is not part of their public API. Change-Id: I97186fcc1d118f922e5ee3cb472aa5b52bc4b5ca
2016-11-02Add FIXMETor Lillqvist
Change-Id: I37e614f6dfa0778cb126a6de282921a15417af1c
2016-11-02xmlsecurity PDF verify: add support for object streamsMiklos Vajna
Adobe Acrobat uses object streams (PDF 1.6) when it signs a PDF exported from LO (PDF 1.4), with this we can verify that signature. If the PDF had at least one signature in LO, then the doc is not upgraded from PDF 1.4, so that was working already. Change-Id: I54b4447ca965a8ba1ffc69bde228ab6f0bda59ee
2016-11-01Use enum class for two local enumsTor Lillqvist
Change-Id: I0d7e6a14ec890b8a1dbdea3685b543b63426c628
2016-10-28xmlsecurity PDF verify: start using offsets from xref streamsMiklos Vajna
This is needed (but not enough) to verify PDF 1.5 signatures. What's missing next is support for object streams. Change-Id: I5afec0a77839ffabe0aaa07e367064210535a1a9
2016-10-28xmlsecurity PDF verify: initial support of cross-reference streamsMiklos Vajna
This adds support for cross-reference streams (which can be used instead of plain-text cross-reference tables) + also one stream predictor. The actual parsed data is still not used, though. Change-Id: Ia806abd8a97636a1bd25dfdafea377b088800f00
2016-10-26xmlsecurity PDF verify: support SHA-256Miklos Vajna
And various other minor fixes. Change-Id: Ifcccebf48aac8ad526406f2d7a402a840d3c91cd
2016-10-26xmlsecurity PDF signing: fix byte range check for multiple signaturesMiklos Vajna
We can mandate that the byte range end is the end of the file for the last signature only. With this, signing a previously unsigned file multiple times works, so add a matching testcase for that as well. Change-Id: I8fe5482890fca4dab8da6305aa7fc7f60df612d8
2016-10-26xmlsecurity PDF signing: only write incremental xref in an incremental updateMiklos Vajna
We used to just dump all the object offsets in the xref of the incremental update, but Adobe Acrobat doesn't like that, and considers that a second signature invalidates the first. If we properly only mention new and changed objects in the xref, then this doesn't happen. This requires actually parsing incremental updates, the previous code depended on LO writing not-really-incremental xrefs at the end of incremental updates. Change-Id: Icdd73fe0a3eab16f8c5a62f1355edbb49f6e73de Reviewed-on: https://gerrit.libreoffice.org/30288 Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk> Tested-by: Jenkins <ci@libreoffice.org>
2016-10-25xmlsecurity PDF sign: append reference to the Page's Annots keyMiklos Vajna
Previously we assumed that the Page object's dictionary has no Annots key. Now detect if that's not true, and in that case don't just copy of the whole dictionary (as part of the incremental update), instead copy it in two steps, so we can insert our reference in the middle. This is needed (but not enough alone) to be able to sign a PDF document multiple times. Change-Id: Ia5bf993320428eef80551e7e9cc7bfb2b858db7f Reviewed-on: https://gerrit.libreoffice.org/30257 Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk> Tested-by: Jenkins <ci@libreoffice.org>
2016-10-24xmlsecurity: implement PDF signature removal UIMiklos Vajna
Unlike with ZIP-based storage, it can happen that the removal fails, so make sure we only remove the signature from the listbox when PDFDocument::RemoveSignature() succeeds. Change-Id: I3241fc11425686bc1ea5452b8f602e053aec0769 Reviewed-on: https://gerrit.libreoffice.org/30224 Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk> Tested-by: Jenkins <ci@libreoffice.org>
2016-10-21xmlsecurity: implement removal of a signature in pdfverifyMiklos Vajna
It's not exactly clear how one should guess what was file end before signing, for now assume the followings: - the file ended with a %%EOF, an optional \r, and a \n - the number of incremental updates is the same as the number of signatures When the later is not the case, don't attempt to remove the signature. Change-Id: I203a7b0605fc061ec6aacfde3a8eedc4736379f2 Reviewed-on: https://gerrit.libreoffice.org/30140 Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk> Tested-by: Jenkins <ci@libreoffice.org>
2016-10-21xmlsecurity PDF export: fix missing /Prev key in the trailer dictionaryMiklos Vajna
"In addition, the added trailer dictionary shall contain a Prev entry giving the location of the previous cross-reference section." (ISO-32000-1, section 7.5.6). Add it, even if it seems Adobe Acrobat can live with not writing it. Change-Id: I1f53e75ebe7dba4b45b3cf1908b2d3b031ef6b02 Reviewed-on: https://gerrit.libreoffice.org/30133 Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk> Tested-by: Jenkins <ci@libreoffice.org>
2016-10-21xmlsecurity: export description in PDF signatureMiklos Vajna
Extract appendUnicodeTextString() from the PDF writer impl, and reuse it in xmlsecurity, to share code. Change-Id: Icdc2f89132cd29e07280001e30bad97e0a644654 Reviewed-on: https://gerrit.libreoffice.org/30110 Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk> Tested-by: Jenkins <ci@libreoffice.org>
2016-10-20xmlsecurity: add initial PDF sign UIMiklos Vajna
An unsigned PDF can be signed now, but the stream still gets truncated on closing the dialog. Change-Id: I12dd50bf577cd23b3355f6c6d03e71a9c0dbcfab
2016-10-18xmlsecurity: initial incremental update support in pdfverifyMiklos Vajna
I plan to use this for signing purposes, but so far what's implemented just writes out an incremental update at the end of the file, without actually updating much (just an unreferenced appearance object). Change-Id: I1cb40430ade6af0a25ff914ba4df670a77fcf457
2016-10-14xmlsecurity: expose reason string of PDF signaturesMiklos Vajna
Also known as comment or description. And since then we need the hex decoding mechanism for this and Content as well, extract that to a new DecodeHexString(). Change-Id: Ie260b470c951661c80c0921b5ce2aa4c461f692c
2016-10-14xmlsecurity: extract certificate from PDF signatureMiklos Vajna
So that the UI can show the correct "Signed by" and "Digital ID issued by" fields. Change-Id: Ied2fed480f48baf60cffb4f0ce762a726beab006 Reviewed-on: https://gerrit.libreoffice.org/29776 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
2016-10-13xmlsecuity: show PDF signature in the doc signatures dialogMiklos Vajna
It doesn't actually show any details yet, but it shows a selectable empty line, to be filled in with details. Change-Id: Ib35f13e5c779fe1a28933c1a0761682e9f5de62d Reviewed-on: https://gerrit.libreoffice.org/29775 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
2016-10-13xmlsecurity: use common NSS init in PDFDocumentMiklos Vajna
The custom code took care of NSS only, the shared code will handle mscrypto as well. Change-Id: I73b904d2e0750d2d847eaaf1ac2b02d41b37d357 Reviewed-on: https://gerrit.libreoffice.org/29763 Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk> Tested-by: Jenkins <ci@libreoffice.org>
2016-10-13xmlsecurity: add initial PDFSignatureHelperMiklos Vajna
This splits most of the PDF signature code out of the pdfverify executable, and puts it into the xmlsecurity library instead. The PDFSignatureHelper now attempts to verify PDF signatures, and code in sdext / sfx2 also calls it (even if PDF is not a ZIP-based format). Change-Id: I7b8b3ac9c976e4ea4f3796b1cda07c8a2c97bd02 Reviewed-on: https://gerrit.libreoffice.org/29751 Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk> Tested-by: Jenkins <ci@libreoffice.org>
2016-10-05convert the last two lonely FixedInfos to FixedTextCaolán McNamara
Change-Id: Ia6ed5f71931a6141efb3d5e5eb329149d6850342
2016-10-05Remove _TYPED suffix from tools/link.hxx macrosStephan Bergmann
...which was introduced with 3ead3ad52f9bb2f9d1d6cf8dfc73a0a25e6778ed "Gradually typed Link" to distinguish the new, typed versions from the old, untyped ones, but is no longer necessary since 382eb1a23c390154619c385414bdbe6f6e461173 "remove untyped Link<>" removed the old versions. Change-Id: I494025df486a16a45861fcd8192dfe0275b1103c
2016-09-13loplugin:override: No more need for the "MSVC dtor override" workaroundStephan Bergmann
The issue of 362d4f0cd4e50111edfae9d30c90602c37ed65a2 "Explicitly mark overriding destructors as 'virtual'" appears to no longer be a problem with MSVC 2013. (The little change in the rewriting code of compilerplugins/clang/override.cxx was necessary to prevent an endless loop when adding "override" to OOO_DLLPUBLIC_CHARTTOOLS virtual ~CloseableLifeTimeManager(); in chart2/source/inc/LifeTime.hxx, getting stuck in the leading OOO_DLLPUBLIC_CHARTTOOLS macro. Can't remember what that isAtEndOfImmediateMacroExpansion thing was originally necessary for, anyway.) Change-Id: I534c634504d7216b9bb632c2775c04eaf27e927e
2016-05-27Get rid of unnecessary directory levels $D/inc/$DTor Lillqvist
Change-Id: Ibf313b8948a493043006ebf3a8281487c1f67b48 Reviewed-on: https://gerrit.libreoffice.org/25532 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Tor Lillqvist <tml@collabora.com> Tested-by: Tor Lillqvist <tml@collabora.com>
2016-05-20Show the certificate use also in the View Certificate dialogTor Lillqvist
Change-Id: I25ba55456be62307348eec529bfd434f8a90bac4
2016-05-19Add column displaying intended usage to certificate chooserTor Lillqvist
The names for the KeyUsage bits defined in RFC3280 are stored in the .ui file for localisation Change-Id: Ia2cbfd28c8a5df6c94d4926fe98ea7048ff41dde
2016-04-14clang-tidy performance-unnecessary-value-param in variousNoel Grandin
Change-Id: I7168d44dab8e6a8e37bb7920d744ff32f5e52907 Reviewed-on: https://gerrit.libreoffice.org/24019 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Noel Grandin <noelgrandin@gmail.com>
2016-04-13tdf#94306 remove unused boost dependenciesJochen Nitschke
remove <boost/noncopyable.hpp> in pch and remove boost from makefile if it was the only boost entry. Change-Id: Icb945ae59c137571f4f63807601738eea5c3e831 Reviewed-on: https://gerrit.libreoffice.org/24061 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Michael Stahl <mstahl@redhat.com>
2016-04-12Avoid reserved identifiersStephan Bergmann
Change-Id: I6075ee18168f19e73c415bf4f0c3423b7a489175
2016-04-02cleanup: remove unused Reference.h(xx) includesJochen Nitschke
and unused using-declarations from Reference.h Change-Id: I297a7ae6044fa329d245ecf08fd5c4cb930f5b19 Reviewed-on: https://gerrit.libreoffice.org/23735 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Markus Mohrhard <markus.mohrhard@googlemail.com>
2016-03-31tdf#97525 vcl: make DeletionListener internalJochen Nitschke
move include/vcl/impdel.hxx to vcl/inc/ include impdel.hxx in salframe.hxx remove vcl/impdel.hxx includes in pch add missing <list> includes Change-Id: Id146363b2e20ce0238542929c26a83efb1e8c4bd Reviewed-on: https://gerrit.libreoffice.org/23664 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Noel Grandin <noelgrandin@gmail.com>
2016-03-14com::sun::star->css in xmlsecurity/Noel Grandin
Change-Id: I4b89f97671ab526e5731d2f1f99802e23f3fd4b5
2016-03-07xmlsecurity OOXML export: remove signature relation with the last signatureMiklos Vajna
The signature relation refers to _xmlsignatures/origin.sigs, but that's not written when all signatures are removed. Change-Id: I5ee1c8849962cba4b338e6f43243bcf89aedad36
2016-03-07xmlsecurity: extract final signature export logic from DigitalSignaturesDialogMiklos Vajna
To be able to unit-test this later without creating a vcl dialog. Change-Id: I4794e212ffefc2efa3bddaf58e6c6bf2a4ea8d9a
2016-03-04xmlsecurity: extract signature removal logic from DigitalSignaturesDialogMiklos Vajna
So that it'll be possible to call that code without an active dialog, from a headless unit test. Change-Id: I1728a666ff5d84b337efd7e2b7eb68469896257a
2016-03-04xmlsecurity OOXML export: only cache existing signatures, not our temp. oneMiklos Vajna
When adding a signature, first we export it to a temp. storage, then read it back, show the verification to the user, and then later we do or do not write the temp. storage back to the original one. This means the signature gets exported two times, and MSO only considers the final result valid. So when caching signatures (to avoid a real export based on our data model), don't cache the one we just added to the temp. storage, but do a real export second time as well. With this, MSO considers our appended signature (next to an existing one) valid, too. Change-Id: I4d615298463e037ea4e654ff5c3addcef8b0a094
generated by cgit (git 2.34.1) at 2025-01-10 05:21:51 +0000