Signing LibreOffice (formerly OpenOffice) documents using OpenPGP

Support
1

This problem, seemingly intractable for me, seems traceable to Whonix constraints… According to Welcome to the LibreOffice Writer Help

LibreOffice uses the OpenPGP software installed in your computer. If no OpenPGP software is available you must download and install one suitable for your operating system, likely from your application store or software distribution channel.

Here are some external GPG applications known to work with LibreOffice:

    gpg4win on Windows

    GPGTools on MacOS

    On Linux, usually already installed:

    gnupg - a command line utility for signing, encrypting and key management.

    Graphical applications for gnupg such as Seahorse (gnome), Kleopatra and KGpg (KDE).

    gpgme - an application program interface (API) to develop applications with GPG.

You must define a personal pair of cryptography keys with the OpenPGP application. Refer to the OpenPGP software installed on how to create a pair of keys, it is usually the first step to execute after the software installation.

I have tried using gpgme but it constantly spits out errors:

The GPGME library returned an unexpected
error at keytable.c:229. The error was:

End of file

This is either an installation problem or a bug in GPA.
GPA will now try to recover from this error.

I then tried gpg-agent just as:

$ gpg-agent

Then, manually giving gpgme an OpenPGP privkey by:

$ cat backups/pgp_keys/privatekey.uid@id-hash.asc | xclip -sel clip

To bring that armoured keyfile into the paste buffer & pasting it to gpgme – no matter what I try, it gives the same error re: keytable.c above.

I need to digitally sign certain business documents and Whonix is my daily driver for my pseudonymous business! While it may seem that the alternative use of pkcs12 or SSL crts might suffice, I rely on the 90-day issuance of my business domain’s SSL certs from LetsEncrypt…

2

This issue seems unspecific to Whonix.

Can be resolved as per:

For developers. Unless you’re a developer (and then you’re better off asking them, not here), then gpgme isn’t for users.

Usually not required nowadays anymore to manually start it.

Unless the issue is not reproducible using Debian, it’s not a Whonix specific issue. Shances are slim somebody here knows how to do that.

The only files that are pre-configured in Whonix are:

  • /etc/skel/.gnupg/dirmngr.conf
  • /etc/skel/.gnupg/gpg.conf

In theory, these might cause issues in corner cases such as this one. Try moving these files out of the way during testing. Then try to reproduce this issue in (an offline) Debian (VM).

3

I have more info! Just noticed:

AVC apparmor="ALLOWED" operation="open" profile="libreoffice-soffice//null-/usr/bin/gpg-agent" name="/proc/8986/fd/" comm="gpg-agent" requested_mask="r" denied_mask="r"
AVC apparmor="ALLOWED" operation="open" profile="libreoffice-soffice//null-/usr/bin/gpg-agent" name="/proc/8987/fd/" comm="gpg-agent" requested_mask="r" denied_mask="r"
AVC apparmor="ALLOWED" operation="open" profile="libreoffice-soffice//null-/usr/bin/gpg-agent" name="/proc/9022/fd/" comm="gpg-agent" requested_mask="r" denied_mask="r"
AVC apparmor="ALLOWED" operation="open" profile="libreoffice-soffice//null-/usr/bin/gpg-agent" name="/proc/9023/fd/" comm="gpg-agent" requested_mask="r" denied_mask="r"
AVC apparmor="ALLOWED" operation="open" profile="libreoffice-soffice//null-/usr/bin/gpg-agent" name="/proc/9105/fd/" comm="gpg-agent" requested_mask="r" denied_mask="r"
AVC apparmor="ALLOWED" operation="open" profile="libreoffice-soffice//null-/usr/bin/gpg-agent" name="/proc/9106/fd/" comm="gpg-agent" requested_mask="r" denied_mask="r"
AVC apparmor="ALLOWED" operation="open" profile="libreoffice-soffice//null-/usr/bin/gpg-agent" name="/proc/9135/fd/" comm="gpg-agent" requested_mask="r" denied_mask="r"
AVC apparmor="ALLOWED" operation="open" profile="libreoffice-soffice//null-/usr/bin/gpg-agent" name="/proc/9136/fd/" comm="gpg-agent" requested_mask="r" denied_mask="r"
4

AVC apparmor=“ALLOWED”
Meaning, the profile is in complain (test) mode. Hence, not enforced.
Therefore AppArmor is not the cause of this issue.

This issue should be reported upstream nonetheless since it would start
causing issues once enforced.