Page MenuHome GnuPG

AppImage of gpg
Closed, ResolvedPublic

Description

Build an AppImage of gpg (with pinentry), so that people using Linux can easily get/install the current official release of gnupg (including all dependencies).

Event Timeline

ikloecker created this task.

One challenge of the AppImage is how to make gpg and its helpers use the helpers baked into the AppImage. Currently, everything is built with prefix /build/AppDir/usr. This causes

gpg: failed to start agent '/build/AppDir/usr/bin/gpg-agent': No such file or directory

unless gpg finds an already running agent.

  • Passing --agent-program /usr/bin/gpg-agent allows using a gpg-agent installed on the system (outside of the AppImage).
  • Inside the AppImage a few environment variables are available, e.g. APPDIR pointing to the temporary mount point used by the AppImage. Adding a wrapper script to the AppImage that adds --agent-program $APPDIR/usr/bin/gpg-agent to the command line passed to the AppImage makes gpg uses the gpg-agent baked into the AppImage. But the pinentry program is still not found. And gpg does not have a documented option to specify the pinentry program to use (gpg-agent has, but that does not help).

Possible solutions:

  1. Add a general option to gpg which allows to specify a path to use for all helpers.
  2. Add special magic for detecting that gpg is inside an AppImage, e.g.
    1. check if there are certain environment variables that are set inside the AppImage. Problem: Those environment variables could also be set outside of an AppImage and they could be abused to make gpg use forged helpers.
    2. Another possibility would be to check if the prefix path built into gpg matches the one we use for the AppImage and only then use the APPDIR environment variable to find its helpers.

Some quick ideas: On Windows we have envvars (and APIs) to determine certain locations. There is also the registry. We use of all them. IT would be best to do this simalar on Unix. We also have a control file on Windows which switches to that portable mode; maybe it is best to do this also on Unix - A text file installed alongside gpg which gpg (common/homedir.c) uses to enable the use of certain envvars to locate the root etc..

I compiled the Appimage with the scripts in Gpg4win and it runs Kleopatra and works :-)

But how do I invoke gpg from this AppImage?

And also for me the scdaemon configuration selftest fails:

There was an error executing the GnuPG configuration self-check for scdaemon:
The configuration file is invalid.
You might want to execute "gpgconf --check-options scdaemon" on the command line.

Is that expected when scdaemon already runs outside of the appimage?

I compiled the Appimage with the scripts in Gpg4win and it runs Kleopatra and works :-)

\o/

But how do I invoke gpg from this AppImage?

You can't. At least, not with this first version of the AppImage. Moreover, I'm not sure whether we should really make this possible. The point of an AppImage is that it encapsulates a single application and not a suit of applications. Nonetheless, it may still make sense to allow invoking gpg and gpgsm and maybe even gpgconf from the AppImage.

And also for me the scdaemon configuration selftest fails:

There was an error executing the GnuPG configuration self-check for scdaemon:
The configuration file is invalid.
You might want to execute "gpgconf --check-options scdaemon" on the command line.

Is that expected when scdaemon already runs outside of the appimage?

Nope. But I think I never tested it with an scdaemon running outside of the AppImage. In any case, mixing daemons running outside of the AppImage with Kleopatra and gpg running in the AppImage is bound to cause trouble. I don't think this is a use case we want to support.

ikloecker raised the priority of this task from High to Needs Triage.

Not sure if we want a separate AppImage for gpg & Co. Setting priority to "Needs Triage".

No, too much release work. Better just one AppImage. Or well one VSD (based on 2.2) and one regular (based on 2.3)

werner changed the task status from Open to Testing.Nov 23 2021, 9:03 AM
werner triaged this task as High priority.
Saturneric added a subscriber: Saturneric.

I found this post when I was searching everywhere for a solution, and I was delighted. I've recently been trying to upload GpgFrontned in the Apple Store vs Microsoft and I'm having some trouble.

The Apple Store requires apps to execute in a sandbox environment, which pretty much disables the possibility of using gpg installed with homebrew. Microsoft's App Store reviewers are also not very friendly with using the additionally installed gnupg package.

It is difficult for gpg2 to be integrated into GpgFrontned as a single module on these two platforms, also including Linux. A separate module, which is packaged with the software ontology and does not depend on any other library or executable file (except libc) that is fixedly installed by the operating system.

I have tried using gpg version 1.4 to solve this problem, but it may be that many features are disabled (such as smart cards). Is there any good solution?

We have everything ready for a GnuPG Desktop Appimage but we first need a business case to maintain it.