/usr/bin/pinentry in platform breaks pinentry

[cmollekopf]

I'm having the issue that org.freedesktop.Platform (I think that's coming from this repository?), ships /usr/bin/pinentry. /usr/bin/pinentry is a symlink to the default pinentry to be used, and is in the platform by default pinentry-curses. Which is not what I want (I want pinentry-qt).

Since I'm just building an application on top org.freedesktop.Platform, it doesn't seem to be possible to remove that file from the platform again, which would hopefully lead to the version in /app/bin/pinentry being picked up which is correctly setup.

To be honest, I couldn't find the place where pinentry is being built to be part of the platform, but:

• Maybe it shouldn't be part of the platform at all?
• Is there some way to remove/or replace it from the applications build manifest (the .json file)?

The only approach that currently works is configuring ~/.gnupg/gpg-agent.conf with "pinentry /app/bin/pinentry" on the host system, but that then breaks gpg for all regular usecases, so not really an option.

[alexlarsson]

It is inherited from the yocto base layer because gnupg recommends pinentry.
I wonder if we should still ship pinentry-curses but drop the symlink. Then apps can re-introduce the symlink by themselves if they want.

[cmollekopf]

If you know of a usecase for pinentry-curses, then maybe that makes sense.
I don't see in which cases pinentry-curses would be useful, without the symlink or some manual configuration gpg-agent.conf I don't think it would be found, and for all graphical applications you'd really want one of the graphical alternatives. Right now I'm ending up with an ncurses dialog on the console when starting a GUI application, which is rather unexpected.

[alexlarsson]

If you have a /app/bin/pinentry ahead of /usr/bin in the PATH, isn't that used instead?

[cmollekopf]

No my inside the container is:
~ $echo $PATH
/usr/lib/ccache/bin/:/app/bin:/usr/bin:/home/chrigi/.fzf/bin

I'm starting to wonder whether gpg-agent has a hardcoded lookup path to /usr/bin...

[alexlarsson]

Maybe a "security" feature...

[alexlarsson]

Its deep in the bowels of "assuan", but yeah, seems like it hardcodes the full path...

[cmollekopf]

always fantastic to do anything with gpg...
So that essentially means that gpg-agent without a custom configuration is not really usable within flatpak, respectively I'd have to build a runtime with pinentry-qt for that.

The two potential other solutions that I can see are:

• Rely on the host gpg-agent and share:
  $ gpgconf --list-dir agent-ssh-socket
  /run/user/1000/gnupg/S.gpg-agent.ssh
• Explicitly start gpg-agent with the --pinentry-program option in the container.

I'm not sure how well option 1 works, especially since we can't control compatibility of what runs on the host and what runs in the container. I'm also not sure how save option 2 is since that means two agents are running on the system...

In either case pinentry in /usr/bin doesn't seem to be the problem after all.

[ramcq]

As a general rule I'd hope that a Flatpak wouldn't generally have access to your secret key material, so sharing ~/.gnupg or ~/.ssh in full might not be that great. I don't know about @alexlarsson but I'd be interested/curious if we could add some minimal support into either Flatpak or a portal for finding the external gpg agent or ssh agent path on the host, and then making it available/usable correctly inside the guest, provided it was priveleged to do so. If it's just "find this socket outside, put it inside" we could have --socket=gpg-agent and/or --socket=ssh-agent for instance?

[cmollekopf]

In my case I'm just mounting the whole homedir, which is perhaps not ideal, but then again I'm not also not using flatpak for additional security. A "proper" way to deal with gpg would indeed be interesting, but I think at least for key-management we'd anyways require access to the keyring (I'm guessing though).

[cmollekopf]

I think this problem just became apparent now because the gpg-agent socket was moved from ~/.gnupg/ to /run/user/..., on another system sharing the agent seems to work.

I have worked around the problem for now by starting my application through a wrapper script, which start gpg-agent with the --pinentry-program option pointing to the right place.

I think the proper solution would be to share gpg-agent, but I see a bootstrapping problem there because gpg-agent would always have to be started on the host system, so the regular process of whatever uses gpg-agent first starts it wouldn't work.

[cmollekopf]

This is the workaround that I'm using currently:

       {
            "name": "kubewrapper",
            "buildsystem": "simple",
            "build-commands": [
                "cp kubewrapper.sh /app/bin/kubewrapper.sh",
                "chmod +x /app/bin/kubewrapper.sh"
            ],
            "sources": [
                {
                    "type": "script",
                    "commands": ["gpg-agent --homedir ~/.gnupg --daemon --pinentry-program /app/bin/pinentry-qt", "kube", "gpg-connect-agent killagent /bye"],
                    "dest-filename": "kubewrapper.sh"
                }
            ]
        }

This allows to work against a gpg-agent with pinentry-qt (to avoid the ncurses version being picked up). We have to kill the agent again at the end because otherwise we'd leak gpg-agents (they will survive even if we original flatpak command is complete.

[cmollekopf]

IMO the proper solution would be to never start gpg-agent inside the container at all. I have no idea how to achieve this with flatpak (I assume some portals magic) but the application should have access to the systems gpg-agent and be able to start it if its not running already.

One way to achieve that is to use socket-activation via systemd (https://www.reddit.com/r/linux/comments/5lzf4a/gnupg_now_ships_systemd_socket_activated_units/). I guess that won't work for all setups (you'll need the socket activation in place), but at least it would be a fairly clean solution.

[ramcq]

I agree, running gpg-agent inside the sandbox seems weird/wrong. Absent a gpg-agent portal, which would be cool, I would explicitly implement --socket=gpg-agent in flatpak, so it would find the environment variable for the gpg agent, or use the helper to start and return the socket, and then bind mount it into a specific path, and set the envvar inside.

[cmollekopf]

Yeah, that solution would be fine as well. I don't think there's a large downside to starting gpg-agent when the flatpak starts instead of when the application first uses gpg.