Page MenuHome GnuPG

AppImage of gpg
Testing, HighPublic

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.Tue, Nov 23, 9:03 AM
werner triaged this task as High priority.