* Add GPG implementation of css::xml::crypto UNO interfaces (part of that is only stub atm)
* List gpg keys along with other certificates
* Viewing gpg certificates: Not all properties are implemented yet
Change-Id: I7f60b26efe949a94bf8fe1b8d4d428002c2995b1
Reviewed-on: https://gerrit.libreoffice.org/33843
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Siegmund Gorr <siegmund.gorr@cib.de>
Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>
so we can remove unnecessary calls to the OUString(literal) constructor
when calling constructors like this:
Foo(OUString("xxx"), 1)
Change-Id: I1de60ef561437c86b27dc9cb095a5deb2e103b36
Reviewed-on: https://gerrit.libreoffice.org/33698
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
The code already knew if the signature was AdES-enabled or not, but that
info wasn't available on the UI.
The values are all names of standards, Andras says it's OK to have them
non-translatable.
Change-Id: I20baf0871fe2c84b04b7fc64014061e341744db8
Reviewed-on: https://gerrit.libreoffice.org/31718
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
Tested-by: Jenkins <ci@libreoffice.org>
It's not useful, OTOH it can happen that something goes wrong and the
result does not match the original.
One situation when this can happen is when non-XAdES signatures are
read, but the checkbox to write XAdES signature is enabled.
Change-Id: Icafad914175b29f7c0245220258bd1420ccd7b9c
Reviewed-on: https://gerrit.libreoffice.org/31437
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
Tested-by: Jenkins <ci@libreoffice.org>
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>
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
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>
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
Also:
- handle PDF in DocumentSignatureManager::write(), so the PDF file is
not truncated when closing the document signatures dialog, and
- handle PDF in DigitalSignaturesDialog::canAddRemove()
Change-Id: I77c1fcdcbdcb079ce934f37546129d9d280e5d2e
DocumentSignatureHelper::isOOo3_2_Signature() checks if the manifest
stream of the ZIP package is signed. A PDF file has no storage, so don't
do that check for that format.
With this, a valid PDF signature is shown as valid in the Digital
Signatures dialog as well.
Change-Id: I58c1cbd665b7c5894d1cfa193061a9370f76c8c4
I left a prefix on the names "Map" so that I would not have to re-arrange
each name too much, since I can't start identifiers with digits like "100thMM"
And remove RSC_EXTRAMAPUNIT, which doesn't seem to be doing anything anymore.
Change-Id: I5187824aa87e30caf5357b51b5384b5ab919d224
Reviewed-on: https://gerrit.libreoffice.org/29096
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Tested-by: Noel Grandin <noel.grandin@collabora.co.uk>
...which was introduced with 3ead3ad52f "Gradually
typed Link" to distinguish the new, typed versions from the old, untyped ones,
but is no longer necessary since 382eb1a23c
"remove untyped Link<>" removed the old versions.
Change-Id: I494025df486a16a45861fcd8192dfe0275b1103c
since...
commit ba81e5c6bd
Date: Thu May 28 21:35:43 2015 +0100
tdf#91702 - fix stack-based MessBox allocation.
There is no special ScopedVclPtr<X>::Create or
ScopedVclPtrInstance<X>::Create just
VclPtr<X>::Create and a raw VclPtr<X>::Create()->foo
doesn't call dispose on the owned X
Change-Id: Ifacc8d5e742820701307c3c37b9b86487667d84f
The odd one out is the usage in Formula, which attempts
to restore focus to a particular window identified by
an unique id. In this case restore focus by keeping a VclPtr
to the desired window.
Change-Id: I1dc335325c109d75745c6bba2e12662e6ae50638
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
Our own importer is happy about the export result already, but MSO is
more picky, and mandates the correct content types for both
_xmlsignatures/origin.sigs and the individual signature streams.
With this, MSO can open the signed file again (while previously it just
declared the file corrupted), though it still declares the signature
invalid.
Change-Id: I199ad96bb91e7ce03fdf1f10f9500db4e05bb5c1
With this, _xmlsignatures/_rels/origin.sigs.rels and
_xmlsignatures/origin.sigs is written to the destination file.
Change-Id: I8d63a182e7cf05ed20195f88c90fba2a9a05379e
When reading a signature, we just take the ODF signature stream or OOXML
signature storage.
When writing, we write to an ODF temporary stream / OOXML temporary
storage, read it back, and only the signatures dialog close handler
writes the signature back to the original file.
The underlying OOXML temporary storage's stream is the signature stream,
so only try to load signatures from the stream if it's not OOXML,
throwing a ZIP file at an XML parser is not a great idea.
Change-Id: I6e42d117b9c97676aaeaad158e78e39a2c39a5e8
In ODF, they're relative to the package root, in OOXML they always start
with a leading slash.
Also, in OOXML the stream URI should have its content type as the
suffix.
Change-Id: Iac570ed15533a23c8a6098f99b716f90e1bac0e0
_rels/origin.sigs.rels of the _xmlsignatures temporary storage now
contains references to the individual signature streams.
Change-Id: I619bd81989e3b62fc4282e0e72fbfa780d1fb8bd
It's an empty file, with the only purpose to have relations, referencing
the individual signature streams. The only tricky part is that a temp
file needs closeOutput() to flush its contents, flush() is not enough.
Change-Id: I92ac61bce201c97a727ff02b1bb74599573a1807
A 'signatures relation' is kind of a pointer that says where is the list
of signatures. When adding the first signature, this has to be created,
in addition to the actual signature relation.
This is yet another difference to ODF signing, where the signature is
just another additional stream in the package, while OOXML signing first
modifies the package to add the signatures relation, and then signs the
streams, so the input storage of the OOXML signing can't be a read-only
storage.
Change-Id: I81a976c945b28ddf7f347c4a7bfd51f98a1fc225
Instead just pass an empty stream, xmlsecurity knows how to look up its
signature storage from the root one.
With this, opening the digital signatures dialog, clicking on add, and
then OK in both dialogs no longer results in an (empty) META-INF storage
written to an OOXML file.
Change-Id: I7e4a93687465ec19be307917ec00cde08ed8092f
First step towards having a working export, since OOXML uses one stream
/ signature, so we need a storage for all signatures, not just a stream.
Change-Id: Id5edfd3ce7e8e4177b0071badc6eb4330a525281
... a signature stream. ODF has a signature stream, OOXML has a
signature storage instead.
Code tries to export all signatures on closing the dialog, but OOXML at
the moment has only an importer; so just fail gracefully in case we only
have a storage, not a stream.
With this, closing the dialog no longer results in a crash for OOXML
documents.
Change-Id: I3e6580ddb20ec31fb0c5a4abe1fab3d8046d0ee5
With this, DigitalSignaturesDialog correctly shows the "Signed by" field
when reading a single valid OOXML signature.
Change-Id: Ic52a56767f65ab30924b07073d31677cb3a27de5
