2016-02-15 11:38:23 +01:00
|
|
|
/* -*- Mode: C++; tab-width: 4; indent-tabs-mode: nil; c-basic-offset: 4 -*- */
|
|
|
|
/*
|
|
|
|
* This file is part of the LibreOffice project.
|
|
|
|
*
|
|
|
|
* This Source Code Form is subject to the terms of the Mozilla Public
|
|
|
|
* License, v. 2.0. If a copy of the MPL was not distributed with this
|
|
|
|
* file, You can obtain one at http://mozilla.org/MPL/2.0/.
|
|
|
|
*
|
|
|
|
* This file incorporates work covered by the following license notice:
|
|
|
|
*
|
|
|
|
* Licensed to the Apache Software Foundation (ASF) under one or more
|
|
|
|
* contributor license agreements. See the NOTICE file distributed
|
|
|
|
* with this work for additional information regarding copyright
|
|
|
|
* ownership. The ASF licenses this file to you under the Apache
|
|
|
|
* License, Version 2.0 (the "License"); you may not use this file
|
|
|
|
* except in compliance with the License. You may obtain a copy of
|
|
|
|
* the License at http://www.apache.org/licenses/LICENSE-2.0 .
|
|
|
|
*/
|
|
|
|
|
2020-11-10 17:38:55 +05:30
|
|
|
#pragma once
|
2016-02-15 11:38:23 +01:00
|
|
|
|
2017-09-05 22:57:54 +02:00
|
|
|
#include "xmlsecuritydllapi.h"
|
2016-10-13 16:11:02 +02:00
|
|
|
|
|
|
|
#include <memory>
|
|
|
|
|
2017-07-09 09:42:01 -04:00
|
|
|
#include <svl/sigstruct.hxx>
|
2017-10-23 22:27:10 +02:00
|
|
|
#include "xmlsignaturehelper.hxx"
|
|
|
|
#include "documentsignaturehelper.hxx"
|
2016-02-15 11:38:23 +01:00
|
|
|
|
2019-04-27 23:53:02 +02:00
|
|
|
#include <com/sun/star/xml/crypto/XSEInitializer.hpp>
|
2022-10-21 18:47:05 +02:00
|
|
|
#include <unotools/tempfile.hxx>
|
2019-04-27 23:53:02 +02:00
|
|
|
|
2020-07-10 15:19:30 +02:00
|
|
|
namespace com::sun::star
|
2018-06-06 21:54:47 +02:00
|
|
|
{
|
|
|
|
namespace beans
|
|
|
|
{
|
|
|
|
struct PropertyValue;
|
|
|
|
}
|
|
|
|
namespace embed
|
|
|
|
{
|
|
|
|
class XStorage;
|
|
|
|
}
|
2020-06-25 14:32:11 +02:00
|
|
|
namespace frame
|
|
|
|
{
|
|
|
|
class XModel;
|
|
|
|
}
|
2018-06-06 21:54:47 +02:00
|
|
|
namespace graphic
|
|
|
|
{
|
|
|
|
class XGraphic;
|
|
|
|
}
|
|
|
|
namespace uno
|
|
|
|
{
|
|
|
|
class XComponentContext;
|
|
|
|
}
|
|
|
|
}
|
2024-11-11 11:36:12 +01:00
|
|
|
namespace svl::crypto
|
|
|
|
{
|
|
|
|
class SigningContext;
|
|
|
|
}
|
2018-01-03 21:06:56 +01:00
|
|
|
class PDFSignatureHelper;
|
cool#9992 lok doc sign: async DocumentDigitalSignatures::ImplViewSignatures()
Currently SfxObjectShell::CheckIsReadonly() has a hack for the LOK case
to show the signatures dialog read-only, as only that is async.
The next step is to make DocumentDigitalSignatures::ImplViewSignatures()
async, though that requires all callers of the function to be async, so
make DocumentDigitalSignatures::signScriptingContent() async as well.
There is also DocumentDigitalSignatures::signPackage(), but turns out
that's dead code, so just remove it.
Once this is in place, we had a problem that the callbacks tried to
interact with libxmlsec, but the dialog was still alive in
DocumentDigitalSignatures::ImplViewSignatures() by the time the callback
was running, so there were two DocumentSignatureManager instances at the
same time, and both assumes it should call the global libxmlsec
init/uninit, which resulted in failing to verify the just created
signature.
Fix this similar to how Tomaz fixed the same problem around pdfium in
commit 067a8a954c8e1d8d6465a4ab5fb61e93f16c26c2 (pdfium: only init
pdfium library one and destroy on LO exit, 2020-06-03).
Change-Id: I3fb63c06195564732e1576dbd755157e676fb762
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/173117
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2024-09-10 10:11:54 +02:00
|
|
|
class Xmlsec;
|
2018-01-03 21:06:56 +01:00
|
|
|
|
2016-02-15 11:38:23 +01:00
|
|
|
/// Manages signatures (addition, removal), used by DigitalSignaturesDialog.
|
|
|
|
class XMLSECURITY_DLLPUBLIC DocumentSignatureManager
|
|
|
|
{
|
2019-05-14 22:53:34 +02:00
|
|
|
private:
|
2016-02-15 11:38:23 +01:00
|
|
|
css::uno::Reference<css::uno::XComponentContext> mxContext;
|
|
|
|
css::uno::Reference<css::embed::XStorage> mxStore;
|
|
|
|
XMLSignatureHelper maSignatureHelper;
|
2016-10-13 16:11:02 +02:00
|
|
|
std::unique_ptr<PDFSignatureHelper> mpPDFSignatureHelper;
|
2016-02-15 11:38:23 +01:00
|
|
|
SignatureInformations maCurrentSignatureInformations;
|
2018-07-20 15:57:13 +02:00
|
|
|
DocumentSignatureMode const meSignatureMode;
|
2016-02-15 11:38:23 +01:00
|
|
|
css::uno::Sequence<css::uno::Sequence<css::beans::PropertyValue>> m_manifest;
|
|
|
|
css::uno::Reference<css::io::XStream> mxSignatureStream;
|
cool#9992 lok doc sign: allow sign of macros & the document itself in one step
Sign a document with macros (via file -> digital signatures -> digital
signatures), realize that you still get a warning on file open, sign the
macros in the document (via tools -> macros -> digital signature),
realize that you did this in the wrong order, so now you have to re-sign
the doc content.
The reason for this is that the macro signature only signs the macro
parts of the document (so you can still edit the document and the
signature is valid, as long as you don't touch macros), while the doc
content signature signs everything, including the macro signature, so
the order of the two matters.
Solve this trouble by adding a new setting that allows doing the two
signatures in one step. Do this by extending the doc content signing
code with an optional pre-step that first signs the document macros.
This is a bit tricky to do, since xmlsecurity/ gets an RW signature
stream and a RO document storage from sfx2/, but transferring one more
signature stream can solve this trouble.
Other tricky parts of the change:
1) The crypto signing is always done by libxmlsec, so
DigitalSignaturesDialog::SetScriptingSignatureStream() has to update
the storage of the sign manager's sign helper, otherwise, the hashes in
the macro signature will be empty.
2) Signing reads the RO storage, so normally the macro signature
would not be part of the doc signature when creating both signatures
inside a single dialog. (The storage is only committed after the
dialog ends.) Fix this problem by extending
DocumentSignatureManager::add() and UriBindingHelper::OpenInputStream()
to provide kind of an overlay when xmlsecurity/ gets a script signature
stream: this way the macro signature will be part of the doc signature
while the dialog is in progress. No overlay is needed later, once both
streams are committed to the storage on dialog end.
Change-Id: Ic2728689997165595991d5ec59c7a2683286e22d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/173263
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
2024-09-12 15:29:33 +02:00
|
|
|
css::uno::Reference<css::io::XStream> mxScriptingSignatureStream;
|
2020-06-25 14:32:11 +02:00
|
|
|
css::uno::Reference<css::frame::XModel> mxModel;
|
2022-10-21 18:47:05 +02:00
|
|
|
rtl::Reference<utl::TempFileFastService> mxTempSignatureStream;
|
2016-02-15 11:38:23 +01:00
|
|
|
/// Storage containing all OOXML signatures, unused for ODF.
|
|
|
|
css::uno::Reference<css::embed::XStorage> mxTempSignatureStorage;
|
2016-11-08 14:10:05 +01:00
|
|
|
css::uno::Reference<css::xml::crypto::XSEInitializer> mxSEInitializer;
|
|
|
|
css::uno::Reference<css::xml::crypto::XXMLSecurityContext> mxSecurityContext;
|
2017-02-02 17:33:30 +01:00
|
|
|
css::uno::Reference<css::xml::crypto::XSEInitializer> mxGpgSEInitializer;
|
|
|
|
css::uno::Reference<css::xml::crypto::XXMLSecurityContext> mxGpgSecurityContext;
|
cool#9992 lok doc sign: async DocumentDigitalSignatures::ImplViewSignatures()
Currently SfxObjectShell::CheckIsReadonly() has a hack for the LOK case
to show the signatures dialog read-only, as only that is async.
The next step is to make DocumentDigitalSignatures::ImplViewSignatures()
async, though that requires all callers of the function to be async, so
make DocumentDigitalSignatures::signScriptingContent() async as well.
There is also DocumentDigitalSignatures::signPackage(), but turns out
that's dead code, so just remove it.
Once this is in place, we had a problem that the callbacks tried to
interact with libxmlsec, but the dialog was still alive in
DocumentDigitalSignatures::ImplViewSignatures() by the time the callback
was running, so there were two DocumentSignatureManager instances at the
same time, and both assumes it should call the global libxmlsec
init/uninit, which resulted in failing to verify the just created
signature.
Fix this similar to how Tomaz fixed the same problem around pdfium in
commit 067a8a954c8e1d8d6465a4ab5fb61e93f16c26c2 (pdfium: only init
pdfium library one and destroy on LO exit, 2020-06-03).
Change-Id: I3fb63c06195564732e1576dbd755157e676fb762
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/173117
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2024-09-10 10:11:54 +02:00
|
|
|
std::shared_ptr<Xmlsec> mpXmlsecLibrary;
|
2016-02-15 11:38:23 +01:00
|
|
|
|
2019-05-14 22:53:34 +02:00
|
|
|
public:
|
2016-02-15 11:38:23 +01:00
|
|
|
DocumentSignatureManager(const css::uno::Reference<css::uno::XComponentContext>& xContext,
|
|
|
|
DocumentSignatureMode eMode);
|
|
|
|
~DocumentSignatureManager();
|
2019-05-14 22:53:34 +02:00
|
|
|
|
2016-02-15 11:38:23 +01:00
|
|
|
/**
|
|
|
|
* Checks if a particular stream is a valid xml stream. Those are treated
|
|
|
|
* differently when they are signed (c14n transformation)
|
|
|
|
*/
|
2022-04-15 16:43:40 +02:00
|
|
|
bool isXML(std::u16string_view rURI);
|
2018-12-24 15:11:30 +01:00
|
|
|
bool readManifest();
|
|
|
|
|
2017-09-01 09:05:00 +02:00
|
|
|
SignatureStreamHelper ImplOpenSignatureStream(sal_Int32 nStreamOpenMode, bool bTempStream);
|
2016-02-15 11:38:23 +01:00
|
|
|
/// Add a new signature, using xCert as a signing certificate, and rDescription as description.
|
2024-11-11 11:36:12 +01:00
|
|
|
bool add(svl::crypto::SigningContext& rSigningContext,
|
2017-06-22 09:06:31 +02:00
|
|
|
const css::uno::Reference<css::xml::crypto::XXMLSecurityContext>& xSecurityContext,
|
2018-05-16 16:34:35 +02:00
|
|
|
const OUString& rDescription, sal_Int32& nSecurityId, bool bAdESCompliant,
|
2018-05-18 08:08:16 +02:00
|
|
|
const OUString& rSignatureLineId = OUString(),
|
2018-07-20 09:06:10 +02:00
|
|
|
const css::uno::Reference<css::graphic::XGraphic>& xValidGraphic
|
2018-05-18 08:08:16 +02:00
|
|
|
= css::uno::Reference<css::graphic::XGraphic>(),
|
2018-07-20 09:06:10 +02:00
|
|
|
const css::uno::Reference<css::graphic::XGraphic>& xInvalidGraphic
|
2018-05-18 08:08:16 +02:00
|
|
|
= css::uno::Reference<css::graphic::XGraphic>());
|
2016-03-04 12:20:38 +01:00
|
|
|
/// Remove signature at nPosition.
|
|
|
|
void remove(sal_uInt16 nPosition);
|
2016-02-15 11:38:23 +01:00
|
|
|
/// Read signatures from either a temp stream or the real storage.
|
xmlsecurity OOXML export: only cache existing signatures, not our temp. one
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
2016-03-04 10:49:12 +01:00
|
|
|
void read(bool bUseTempStream, bool bCacheLastSignature = true);
|
2016-03-07 09:58:12 +01:00
|
|
|
/// Write signatures back to the persistent storage.
|
2016-11-09 15:14:03 +02:00
|
|
|
void write(bool bXAdESCompliantIfODF);
|
2016-10-13 16:11:02 +02:00
|
|
|
/// Lazy creation of PDF helper.
|
|
|
|
PDFSignatureHelper& getPDFSignatureHelper();
|
2016-10-29 09:50:28 +03:00
|
|
|
#if 0
|
|
|
|
// Checks if the document is a kind where it is relevant to distinguish between using XAdES or not
|
|
|
|
bool IsXAdESRelevant();
|
|
|
|
#endif
|
2016-11-08 14:10:05 +01:00
|
|
|
/// Attempts to initialize the platform-specific crypto.
|
|
|
|
bool init();
|
|
|
|
/// Get the security environment.
|
|
|
|
css::uno::Reference<css::xml::crypto::XSecurityEnvironment> getSecurityEnvironment();
|
2017-02-02 17:33:30 +01:00
|
|
|
css::uno::Reference<css::xml::crypto::XSecurityEnvironment> getGpgSecurityEnvironment();
|
2019-09-28 14:22:40 +02:00
|
|
|
css::uno::Reference<css::xml::crypto::XXMLSecurityContext> const& getSecurityContext() const;
|
|
|
|
css::uno::Reference<css::xml::crypto::XXMLSecurityContext> const& getGpgSecurityContext() const;
|
2019-05-14 22:53:34 +02:00
|
|
|
void setStore(const css::uno::Reference<css::embed::XStorage>& xStore) { mxStore = xStore; }
|
|
|
|
XMLSignatureHelper& getSignatureHelper() { return maSignatureHelper; }
|
2020-04-08 12:36:53 +02:00
|
|
|
bool hasPDFSignatureHelper() const { return bool(mpPDFSignatureHelper); }
|
2019-05-14 22:53:34 +02:00
|
|
|
void setSignatureStream(const css::uno::Reference<css::io::XStream>& xSignatureStream)
|
|
|
|
{
|
|
|
|
mxSignatureStream = xSignatureStream;
|
|
|
|
}
|
2024-11-07 11:54:09 +02:00
|
|
|
const css::uno::Reference<css::io::XStream>& getSignatureStream() const
|
|
|
|
{
|
|
|
|
return mxSignatureStream;
|
|
|
|
}
|
cool#9992 lok doc sign: allow sign of macros & the document itself in one step
Sign a document with macros (via file -> digital signatures -> digital
signatures), realize that you still get a warning on file open, sign the
macros in the document (via tools -> macros -> digital signature),
realize that you did this in the wrong order, so now you have to re-sign
the doc content.
The reason for this is that the macro signature only signs the macro
parts of the document (so you can still edit the document and the
signature is valid, as long as you don't touch macros), while the doc
content signature signs everything, including the macro signature, so
the order of the two matters.
Solve this trouble by adding a new setting that allows doing the two
signatures in one step. Do this by extending the doc content signing
code with an optional pre-step that first signs the document macros.
This is a bit tricky to do, since xmlsecurity/ gets an RW signature
stream and a RO document storage from sfx2/, but transferring one more
signature stream can solve this trouble.
Other tricky parts of the change:
1) The crypto signing is always done by libxmlsec, so
DigitalSignaturesDialog::SetScriptingSignatureStream() has to update
the storage of the sign manager's sign helper, otherwise, the hashes in
the macro signature will be empty.
2) Signing reads the RO storage, so normally the macro signature
would not be part of the doc signature when creating both signatures
inside a single dialog. (The storage is only committed after the
dialog ends.) Fix this problem by extending
DocumentSignatureManager::add() and UriBindingHelper::OpenInputStream()
to provide kind of an overlay when xmlsecurity/ gets a script signature
stream: this way the macro signature will be part of the doc signature
while the dialog is in progress. No overlay is needed later, once both
streams are committed to the storage on dialog end.
Change-Id: Ic2728689997165595991d5ec59c7a2683286e22d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/173263
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
2024-09-12 15:29:33 +02:00
|
|
|
void setScriptingSignatureStream(
|
|
|
|
const css::uno::Reference<css::io::XStream>& xScriptingSignatureStream)
|
|
|
|
{
|
|
|
|
mxScriptingSignatureStream = xScriptingSignatureStream;
|
|
|
|
}
|
2020-06-25 14:32:11 +02:00
|
|
|
void setModel(const css::uno::Reference<css::frame::XModel>& xModel);
|
2019-09-28 14:22:40 +02:00
|
|
|
const css::uno::Reference<css::embed::XStorage>& getStore() const { return mxStore; }
|
2019-05-14 22:53:34 +02:00
|
|
|
DocumentSignatureMode getSignatureMode() const { return meSignatureMode; }
|
|
|
|
SignatureInformations& getCurrentSignatureInformations()
|
|
|
|
{
|
|
|
|
return maCurrentSignatureInformations;
|
|
|
|
}
|
2016-02-15 11:38:23 +01:00
|
|
|
};
|
|
|
|
|
|
|
|
/* vim:set shiftwidth=4 softtabstop=4 expandtab: */
|