Feature Request; Qubes "Split GPG" Not Working (Linux)

[sw4k]

Problem

It seems GpgFrontend relies on gpg-agent, and/or, it uses a hardcoded path to the gpg command-line tool and I don't see any method of changing this (v2.1.2).

Am I overlooking it?

Solution

Can the GpgFrontend developer(s) add a feature to make the use of command-line gpg tool with a GUI option that will easily override/configure the command-line tool being used?

Justification

Qubes OS offers a "Split GPG" configuration which isolates keys from unauthorized access at ring0. This greatly enhances security of private keys. Because GpgFrontend doesn't seem to allow the configuration of the command-line tool being used it doesn't seem able to participate in Split GPG configurations.

[saturneric]

Currently, GpgFrontend does offer the capability to customize the use of GnuPG through the GnuPG Controller. However, to prevent accidental misconfigurations by users, the customization requires specifying the path to gpgconf rather than directly to the gpg executable. This approach is taken to ensure safety, as GpgFrontend executes gpgconf to retrieve the gpg executable's path and then uses this path for all related operations. This method helps in maintaining a layer of abstraction and safety for users, ensuring that the correct gpg configuration is applied.

Would this approach meet your requirements for integrating with the Split GPG setup in Qubes OS? It's designed to provide both the flexibility for advanced configurations like yours and to minimize the risk of potential misconfigurations.

Let me know if this solution works for you or if there are any further details or assistance you require.

[saturneric]

Additionally, I'd like to point out that it is indeed possible for users to modify the address pointing to the gpg executable within gpgconf. This can be done through specific means, allowing for further customization of the GnuPG setup used by GpgFrontend. For detailed instructions on how to achieve this, I recommend consulting the gpgconf man page, which provides comprehensive guidance on modifying its configuration.

[sw4k]

That makes sense. Let me work through this, it sounds like it will work. I'll provide example/instruction here for anyone else that might need it, then close this out. Your follow-up is very much appreciated, seems to point me in the right direction. Thank you.

[sw4k]

Hi @saturneric , so I've officially hit a wall.

I read through all man pages for gpg, gpg-agent, gpgconf, and could not find any method of controlling which gpg binary is used. I did a decent amount of research online to see if maybe there was an env-var or some undocumented feature that could be used, and that didn't prove useful. I then pulled the source for gnupg and started going through the code and it appears that the binary paths seen from gpgconf --list-components and gnuconf --check-programs are hardcoded (non-configurable, build-time values), I believe the code responsible for resolving these paths comes from homedir.c function gnupg_module_name(int which); within that function is a switch statement which constructs a program (aka "module") path in the following way:

    case GNUPG_MODULE_NAME_GPG:
#if USE_GPG2_HACK
      if (! gnupg_build_directory)
        X(bindir, "g10", GPG_NAME "2");
      else
#endif
        X(bindir, "g10", GPG_NAME);

Where X() is a macro that constructs a path. There is an env-var for development use to point the toolchain at a different folder, but the value of GPG_NAME cannot be changed post-build.

If I am mistaken then some assistance would be greatly appreciated at this point, I've made three passes at this over the last week or so and every avenue leaves me without a solution. Going through the source code was my last best option.

The only mechanism I can find to redirect GpgFrontend to use Qubes Split GPG is modifying the rootfs by renaming the default gpg binary and creating a symlink in its place to point at the Qubes GPG client proxy/wrapper. The easiest way to do this is by modifying the TemplateVM which means every AppVM instance is reconfigured, which is not really "the Qubes way". There is a hackish approach to accomplish this by creating rc.local scripts on the rwfs to rewrite rootfs during vm boot/init but this is a fairly complicated approach. If there is no other option, I will probably resort to modification of rootfs during vm boot/init.

If I am overlooking something let me know, the above code reference is what determines paths for all components in all gnupg tools (including gpg-agent and gnuconf.) The only program that appears to offer users the ability to override the program path via conf files is "pinentry".

[saturneric]

Hi @sw4k ,

The gpgconf --build-prefix option might not fully address your requirements as it's intended for specifying the installation prefix of the GnuPG system during build time, rather than dynamically changing the GPG binary path at runtime. Your exploration into redirecting GpgFrontend to use Qubes OS's Split GPG functionality indicates a need for a more tailored solution.

I appreciate the depth of your investigation and the potential need for modifications and adaptations specific to the Qubes platform. Implementing such changes could indeed take some time, especially considering the necessity to install the system, familiarize oneself with its functionalities, and then proceed with the actual modifications.

If you're willing, your assistance could significantly accelerate this process. A good starting point would be to delve into the source code of GpgFrontend, particularly focusing on how GpgContext is initialized within the files GpgCoreInit.cpp and GpgContext.cpp. This exploration might reveal opportunities for enhancements or adaptations to accommodate your needs. Furthermore, if you are a developer with available time, your direct contributions through a Merge Request (MR) would be incredibly valuable.

This collaborative effort could not only address your immediate needs but also potentially benefit the wider community of users who might be in similar situations.

[sw4k]

Sounds good, I'll pull sources this weekend and get familiar. Not a problem.