Previously, WindowsErrorString and WindowsErrorStringFromHRESULT were
defined in an anonymous namespace in windowserrorstring.hxx, which:
1. Made them unavailable to other translation units
2. Violate ODR by creating separate copies in each TU
3. Require workarounds to access them
Changes:
- Move functions to proper comphelper namespace
- Keep implementations inline as they're simple utilities
- Preserve all existing functionality
- Update all call sites to use comphelper:: prefix
This change enables proper use of these utilities across LibreOffice
while maintaining current behavior and performance characteristics.
Introduced in this commit:
commit 94cdcaa4d8
Author: Tor Lillqvist <tml@collabora.com>
Date: Thu Aug 13 13:22:28 2015 +0300
Add a globally usable WindowsErrorString function
Change-Id: I34df1c2b1f30c6204f107ca4792131d692203880
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/183332
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Tested-by: Jenkins
See commit 1817760f56 (tdf#161872
xmlsecurity nss: don't require trusted signing certs, 2025-01-28), this
is the same situation, but this time on Windows.
Change-Id: I945899da47ab5dcc421f35db31ec7af240c59b8c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/180881
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
Configure your signing cert in Firefox, (unusually) don't trust the CA
that you would use to issue your signing cert, try to sign a document,
error.
This is reportedly wrong since commit
bfd479abf0 (Update libxmlsec to 1.3.1,
2023-06-09), for some reason our usage of libxmlsec-1.2 didn't trigger
this problem.
Given that we already disable libxmlsec-side cert verify while
verifying a signature (and have our own logic there), it's consistent to
do the same while creating the signature, and that fixes the bug, too.
The Windows / MSCNG backend is not yet changed here.
Change-Id: I8a7adf06b9a26731f1a180a4f6257317084e414a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/180844
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
No functional changes intended:
- Replace SfxObjectShell::GetSignPDFCertificate() and
SfxObjectShell::ResetSignPDFCertificate() with
SfxViewShell::SetSignPDFCertificate() and
SfxViewShell::GetSignPDFCertificate(), because information about shape
selection belongs to the view.
- Change svx::SignatureLineHelper::setShapeCertificate() to use
SfxViewShell::SetSignPDFCertificate() to avoid duplication.
- Change GetSignatureLineShape() in xmlsecurity/ to use
SfxViewShell::GetSignPDFCertificate(), again to avoid duplication.
With this, all setters/getters of the inserted signature line go via
SfxViewShell and the amount of getCurrentSelection() calls on the model
is reduced.
Change-Id: I021bc41262b2a16d1014fbf1431a0eb6e1e86c73
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/180355
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
Have electronic signing configured in the LOK client, try to insert a
signature line, you'll get a certificate picker, while we don't have a
cert during esign.
What's in fact needed for creating the signature line is just a name
(previously extracted from the certificate), we can survive the lack of
actual certificate.
Fix the problem by adding a new External parameter to
.uno:InsertSignatureLine to hint that the certificate chooser should not
be opened, instead the editor name (used for comments already) should be
used. Add a new CertificateOrName in svl/ and use that in all places
where previously we wanted a certificate but in fact it's enough to have
a certificate or a name to create the signature line.
The name on the signature line is just visual feedback, the actual name
on the crypto signature is still not based on untrusted used input.
Change-Id: Ib7008112a8e28a9e7d9649745e6021dd6b6b9c39
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/180193
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Once .uno:InsertSignatureLine gets dispatched, a visual signature
placeholder gets inserted, then a certificate picker shows up, but no
certificates are visible in the list.
The first problem is that .uno:InsertSignatureLine needs to take sign
key/cert parameters in DrawViewShell::FuPermanent() (similar to
.uno:Signature), so it can learn what certificate to use for signing.
The second problem is that once that sign cert is attached to the view,
the cert chooser for signature lines were not taking the sign cert from
the view in DocumentDigitalSignatures::chooseCertificatesImpl() -- this
needs routing the info about the current view from sd/ (where we still
have that info) to xmlsecurity/.
With this, a LOK client dispatching .uno:InsertSignatureLine with the 2
new parameters set can insert a signature line, it'll show up, but the
subsequent .uno:Signature dispatch still needs fixing up. (Currently it
wants to "save" the modified PDF, while it should just sign.)
Change-Id: Ie536842152ef097aa6959c67916f2beb6d356e4a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/179819
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Rename weld::TreeView member + methods to clarify
that these are about selection changes:
* m_aChangeHdl to m_aSelectionChangedHdl,
* signal_changed to signal_selection_changed
* connect_changed to connect_selection_changed
In GtkInstanceTreeview, also rename the
related methods calling signal_selection_changed
accordingly for consistency.
Change-Id: I299d7930484677395a0bdd0ff105df18688f2e04
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/178023
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
The final goal of this API is to give time & hash information about the
PDF signature, so once a 3rd-party produces the PKCS#7 signature, that
can be added to the document and the actual PDF sign can be re-run with
the same parameters.
This commit continues the replacement of XCertificate with
svl::crypto::SigningContext up to the point that the timestamp used in
svl/ can be exposed on the LOK API.
This is done by updating DocumentSignatureManager::add(),
PDFSignatureHelper::SetX509Certificate(),
vcl::filter::PDFDocument::Sign() and finally the svl::crypto::Signing
ctor to work with the signing context instead of an XCertificate
directly.
Time reporting works now, so add a test for that. The digest part still
needs doing.
Change-Id: I83f1274cd420b67194b7caf12b1027e623d4f7fe
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/176404
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
The trouble with signing via ca/cert/key PEM files is that usually the
CA is not trusted by the received of the signature. 3rd-party services
are available to do generate trusted signatures, but then you need to
share your document with them, which can be also problematic.
A middle-ground here is to sign the hash of the document by a 3rd-party,
something that's supported by e.g.
<https://docs.eideasy.com/electronic-signatures/api-flow-with-file-hashes-pdf.html>
(which itself aggregates a number of providers).
As a first step, add LOK API to get what would be the signature time
during signing -- but instead of actually signing, just return this
information. Once the same is done with the doc hash, this is supposed
to provide the same info than what the reference
<https://github.com/eideasy/eideasy-external-pades-digital-signatures>
app does.
This is only a start: incrementally replace XCertificate with
SignatureContext, which allows aborting the signing right before calling
into NSS, and also later it'll allow injecting the PKCS#7 object we get
from the 3rd-party.
Change-Id: I108564f047fdb4fb796240c7d18a584cd9044313
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/176279
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
we can just take a "const &".
(found by running clang-tidy with the
performance-unnecessary-copy-initialization warning)
Change-Id: I20fd208c65303da78170b1ac06c638fdf3aa094b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/176267
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Tested-by: Jenkins
This ctor is meant to set the value of nTime directly; and that value
is not nanoseconds, but an encoded value, using SEC_/MIN_/HOUR_MASK.
But in some places, this ctor was misused for setting of nanoseconds,
which would only accidentally work for values less than one second.
All places that initialized tools::Time with 0, now use EMPTY.
This makes the ctor private; and for the very few cases where really
the encoded value of nTime is stored / restored, fromEncodedTime is
introduced.
Change-Id: I1f1994bd9aab1b51a41b1de637619049fe820da4
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/175283
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Since
commit ad6f23d2a3
Author: TokieSan <eltokhy@aucegypt.edu>
Date: Tue Jul 18 21:54:31 2023 +0300
Added searching and filtering features to certificate chooser dialog
V501 There are identical sub-expressions 'rCharClass.uppercase(sIssuer).indexOf(aSearchStr) < 0' to the left and to the right of the '&&' operator.
Change-Id: Ifdc4b371e6d8f79ad43236e10b86e8e5b03204a9
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/175284
Tested-by: Jenkins
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
1) Move the try-catch around assing a signature inside the block that
already got the response from the certificate chooser, it's unlikely
that choosing the certificate (and not yet signing) would fail.
2) Convert the dialog to async and allow it to be a jsdialog.
3) Hide not relevant widgets for LOK: we have a single signing
certificate, so the search entry is not useful.
The refresh button has an unclear purpose, as it was initially added
in commit fb9874231f (Caching
Certificates in the CertificateChooser dialog session-wise, 2023-08-26),
but later commit efe414c4a8 (Don't reuse
CertificateChooser instances, 2024-02-07) disabled this chaching. In any
case, the certificate won't change during the lifetime of a single LOK
view, so hide that as well.
4) Invoke the inner certificate viewer in an async way, too.
Change-Id: Ibf618ea7632cf801d1d9180b9aa7dd193c45ffda
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/174215
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
Have two views, in case both of them haver sign certs configured in the
NSS database, then the cert chooser would present both, which is not
wanted.
The problem is that the NSS database contains sign certs from all views,
so working from the database is not what we want for the LOK case.
Fix the problem by passing the SfxViewShell from the sign dialog to the
certificate chooser dialog, and then the chooser can work from the view
in LOK mode.
Searching for other uses of getPersonalCertificates(), the comphelper/
one is not relevant for the LOK case (gpg is disabled there); the PDF
case is only for the UNO API, so those don't necessarily need adjusting.
Change-Id: Ic7027b8d218b2bde3c8bf134a4b11c14fd9c3570
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/174002
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
Open the sign dialog, the Add button is hidden, even if the LOK clients
initializes the view with a working signing certificate.
SfxMedium::SignContents_Impl() knows the correct view, but by the time
the execution arrives to the DigitalSignaturesDialog ctor, this info is
lost, so we don't know what is the current view.
Fix the problem by looking up the view of the object shell at UNO
command dispatch time, and passing that around, so the signature dialog
can also access it. If the view has a signing certificate configured,
then allow signing.
The certificate chooser triggered by this button still needs fixing.
Change-Id: I1fae63cea27ea1e68e938879f4507f53ade484f1
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/173964
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
Once the signing key is taken from the matching SfxViewShell (not yet
done), signing with a certificate specified via initializeForRendering()
failed with:
warn:xmlsecurity.xmlsec:13020:13005:xmlsecurity/source/xmlsec/nss/x509certificate_nssimpl.cxx:330: X509Certificate_NssImpl::getPrivateKey() cannot find private key
warn:xmlsecurity.xmlsec:13020:13005:xmlsecurity/source/xmlsec/nss/securityenvironment_nssimpl.cxx:812: Can't get the private key from the certificate.
warn:xmlsecurity.xmlsec:13020:13005:xmlsecurity/source/xmlsec/errorcallback.cxx:53: keys.c:1347: xmlSecKeysMngrGetKey() '' '' 45 'details=NULL'
warn:xmlsecurity.xmlsec:13020:13005:xmlsecurity/source/xmlsec/errorcallback.cxx:53: xmldsig.c:822: xmlSecDSigCtxProcessKeyInfoNode() '' '' 45 'details=NULL'
warn:xmlsecurity.xmlsec:13020:13005:xmlsecurity/source/xmlsec/errorcallback.cxx:53: xmldsig.c:537: xmlSecDSigCtxProcessSignatureNode() '' 'xmlSecDSigCtxProcessKeyInfoNode' 1 ' '
warn:xmlsecurity.xmlsec:13020:13005:xmlsecurity/source/xmlsec/errorcallback.cxx:53: xmldsig.c:301: xmlSecDSigCtxSign() '' 'xmlSecDSigCtxProcessSignatureNode' 1 ' '
The trouble was that we wanted to keep the private key in-memory,
presumably because initially the whole NSS database was in-memory for
the LOK case. This was changed in commit
87eec1b90b (NSS: create a temporary
database instead of in-memory, 2018-12-31), so there is no problem with
a not-in-memory private key anymore.
Note that the problematic codepath was only triggered when first the
certificate chooser was ran and only then we signed. So the testcase
also gets the cert flags before signing, otherwise the test would
succeed even without the fix.
Change-Id: I5086b205c91b630ddd343c0eb91bd9e63b3ea238
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/173892
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
Open an already signed document, click on the sign icon on the status
bar, notice how the button to remove a signature is hidden.
This was added in commit 71a8bad4b9
(jsdialog: enable Digital Signatures dialog, 2022-01-24), which exposed
the signatures dialog as a read-only jsdialog. The dialog was improved
recently to be a read-write jsdialog, so this is no longer needed.
But then DigitalSignaturesDialog::canRemove() had an inner non-async
message dialog. Fix that by converting canRemove() to async.
An additional problem could be that the document is not marked as
modified, so the LOK client code doesn't notice the document is updated
(to not have a signature), but we do update the last mod timestamp of
the file, which is meant to be enough.
Change-Id: I8e7ee22e4b1b8ce59dee3617bb2f22f8d734f31d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/173428
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
Some functions were already a stub and only aborted on calling them.
The *Package* functions were added in commit
c9ed2f359a (INTEGRATION: CWS xmlsec08
(1.4.24); FILE MERGED 2005/02/22 13:07:19 mt 1.4.24.1: #i36682# Accept
separate Stream for signatures..., 2005-03-10), but it seems nobody
called them.
This also means that DocumentSignatureMode is now never set to
DocumentSignatureMode::Package, so remove that as well.
It seems to be unlikely that this non-published service was used by
3rd-party code, since it was specific to the needs of sfx2/ code, not
generic functionality that could be useful in other contexts.
Change-Id: Icfed9a0e6568f6eb21f9236901af01f1915bf2f8
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/173313
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
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
This finally allows removing the hack for the LOK case in
SfxObjectShell::CheckIsReadonly() to show the signatures dialog
read-only.
Also fix a case while signing PDFs where the file stream was on the
stack, but now that we finish signing in an async callback, signing
crashed due to a use-after-free.
Fix that by giving the std::unique_ptr to the utl::OStreamWrapper ctor,
which knows to take over ownership in this case, and that wrapper is
reference-counted.
Next problem is that the add/remove buttons in the dialog are still
hidden in the LOK case, that's not yet fixed here.
Change-Id: I71ee50ae55d4e62f5d265a35e3810e3b2b63a9b9
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/173155
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
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 067a8a954c (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>
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::signDocumentContent() async, but passing an
std::function via the UNO API is tricky.
Notice how DocumentDigitalSignatures in xmlsecurity/ also implements
sfx2::DigitalSignatures, add a new SignDocumentContentAsync() there and
adapt all uses of signDocumentContent() to go with that instead.
This requires introducing some lambdas for code after
signDocumentContent() in general and for ODF/OOXML specific code in
particular, to avoid code duplication.
Change-Id: If771ced711041364988af45ad9dd0dd1a2a8660d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/173060
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
The NSS password dialog naming the Mozilla profile only shows up for
X.509 certs outside Windows. And the user may wrongly assume GPG keys
are from Thunderbird.
Change-Id: I23706309d57fe30cddcbcac16d7f3e20ee397f16
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/171645
Tested-by: Jenkins
Reviewed-by: Thorsten Behrens <thorsten.behrens@allotropia.de>
When selecting a X.509 cert on Unix/Linux/macOS. (ODF+PDF signing)
Helps the user to know which password is requested.
Previously only asked for the "NSS Certificate DB" password.
Change-Id: Ic44d3c4b2f98185c07b11f9880d64016aa0b60ca
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/171641
Tested-by: Jenkins
Reviewed-by: Thorsten Behrens <thorsten.behrens@allotropia.de>
Before this change, selecting only GPG keys for ODF encrpytion relied on
the fact, that all X.509 implementations (nss+mscrypt) implement listing
public keys (getAllCertificates) as a stub.
See previous change Ia6b8ecb9
Change-Id: Icb36a4cefd60b94407129ff73fe62f9250bfbee5
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/171639
Tested-by: Jenkins
Reviewed-by: Thorsten Behrens <thorsten.behrens@allotropia.de>
For ODF encryption, only GPG keys are allowed. And key selection for this currently only works correctly, because all X.509 implementations (nss and mscrypt) yield empty results when asked for public keys (encryption).
This commit is a first step to make the selection for GPG keys explicit.
Other code still needs to be changed to make use of this new function
argument.
Change-Id: Ia6b8ecb901c0f54a9a58b1bd0efaa7154ffbd285
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/171638
Tested-by: Jenkins
Reviewed-by: Thorsten Behrens <thorsten.behrens@allotropia.de>
fix GPG CertificateImpl::getSHA1Thumbprint not returning a
sequence of bytes as the thumbprint. (that is what the
documented API states, and what all of the code assumed.)
now /org.openoffice.UserProfile/Data/signingkey and
encryptionkey stores the key's SHA1Thumbprint for better
identification of keys. Previously on the key name was being
used.
fix annoying NSS Certificate Database password prompt
appearing on Tools->Options if the certificate database is
password protected.
improve Tools->Options->UserData user key selection and
display of information.
add a ui test for "Sign with default certificate"
interaction in the save dialog.
Change-Id: I1036856003f58f494838e0f81ca0fe18e821f528
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/171395
Tested-by: Jenkins
Reviewed-by: Sarper Akdemir <sarper.akdemir@allotropia.de>
The commit broke the display of all columns except the first one in all
backends except gtk3.
Also it's not clear why those columns are deemed superfluous;
see discussion in tdf#161871
This reverts commit 9f327102c4.
Change-Id: Idc3496122137f98c23bb7df8e36b17281fc948d3
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/170491
Tested-by: Jenkins
Reviewed-by: Samuel Mehrbrodt <samuel.mehrbrodt@allotropia.de>
Usuccessful signing sessions (e.g. abort when password is requested)
left their key in the context.
On the next try, the former key would also be used to sign.
Change-Id: I55b9201df229cae40863a0a19b238029607d1848
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/170388
Reviewed-by: Samuel Mehrbrodt <samuel.mehrbrodt@allotropia.de>
Tested-by: Jenkins
Seeing as since:
commit e9531b792d
Date: Tue Feb 6 14:39:47 2024 +0100
sal: rtlRandomPool: require OS random device, abort if not present
Both rtl_random_createPool() and rtl_random_getBytes() first try to get
random data from the OS, via /dev/urandom or rand_s() (documented to
call RtlGenRandom(), see [1]).
we don't use the initial arg to rtl_random_getBytes anymore, drop the
requirement to have one. Then simplify our usages of that, and
addtionally deprecate rtl_random_createPool and rtl_random_destroyPool.
Change-Id: I13dcc067714a8a741a4e8f2bfcf2006373f832c4
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/167067
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
Mike Kaganski