search

flathub / org.claws_mail.Claws-Mail

https://flathub.org/apps/details/org.claws_mail.Claws-Mail
4 stars 1 forks source link

Introduce pinentry #7

Closed cobratbq closed 4 years ago

cobratbq commented 4 years ago

Introduce pinentry to Claws-Mail package and use wrapper-script to ensure gpg-agent is started with necessary start-up parameters before executing Claws-Mail.

This fixes #5. @Enpheebled can you verify once build-bot is ready?

Unresolved:

flathubbot commented 4 years ago

Started test build 13018

flathubbot commented 4 years ago

Build 13018 successful To test this build, install it from the testing repository:

flatpak install --user https://dl.flathub.org/build-repo/12424/org.claws_mail.Claws-Mail.flatpakref
cobratbq commented 4 years ago

@Enpheebled run flatpak install --user https://dl.flathub.org/build-repo/12424/org.claws_mail.Claws-Mail.flatpakref to install from test repository. (See also https://github.com/flathub/org.claws_mail.Claws-Mail/pull/7#issuecomment-568935280)

Erick555 commented 4 years ago

Did you tested --socket=pcsc permission for smartcard support (requires flatpak 1.3.2+)?

To share gpg-agent socket from host simply add --filesystem=xdg-run/gnupg:ro permission.

cobratbq commented 4 years ago

Did you tested --socket=pcsc permission for smartcard support (requires flatpak 1.3.2+)?

Yes. It will show the dialog asking for smartcard with specific serial. Then not find it while it is inserted. I think flatpak-builder may be the problem here. Behavior seems to be the same regardless of whether I add the --socket=pcsc line to the manifest.

$ flatpak --version
Flatpak 1.4.3
$ flatpak-builder --version
flatpak-builder 1.0.9
$ flatpak-builder --socket=pcsc --run build org.claws_mail.Claws-Mail.json /app/bin/claws-mail-wrapper.sh
Option parsing failed: Unknown socket type pcsc, valid types are: x11, wayland, pulseaudio, session-bus, system-bus, fallback-x11

It also does not matter whether I run from local build directory, or install it first and run through flatpak run org.claws_mail.Claws-Mail.

To share gpg-agent socket from host simply add --filesystem=xdg-run/gnupg:ro permission.

This indeed works, although write-permissions are necessary. (No they're not, but gpg-agent needs to be running on the host.) By using the host gpg-agent process pcsc/smartcard is accessible too. I'll look into this some more to see if this is a better solution. Specifically, I need to be sure the behavior doesn't cause problems if no gpg-agent is running yet, and Claws-Mail would start it.

NOTE that the test package in the PR contains my host's /etchosts file. (Containing extensive blocking lists.) I also need to check how I can avoid that. So not ready for prime-time yet. Nevermind. I'm an idiot :-P

cobratbq commented 4 years ago

For the record: I am (still) not able to ensure gpg-agent runs locally such that I can pass-through xdg-run/gnug by default to org.claws_mail.Claws-Mail. However, what does work is starting the Claws-Mail flatpak with an additional command-line parameter: (This assumes the standard Claws-Mail flatpak package is installed.)

gpg-agent && flatpak run --filesystem=xdg-run/gnupg:ro org.claws_mail.Claws-Mail

This ensures that Claws-Mail will only start if gpg-agent is running on the host system and then xdg-run/gnupg is passed-through read-only for Claws-Mail to use. This can function as a workaround in case you occasionally need access to your smartcard from within Claws-Mail.

Erick555 commented 4 years ago

Could you show systemctl --user status gpg-agent.socket output?

Maybe you can also try --filesystem=xdg-run/gnupg:create

cobratbq commented 4 years ago

Could you show systemctl --user status gpg-agent.socket output?

$ systemctl --user status gpg-agent.socket

Unit gpg-agent.socket could not be found.

I typically run gpg --card-status and afterwards an instance of gpg-agent is available. It is a workaround, I know, but it was sufficient for the time being.

Maybe you can also try --filesystem=xdg-run/gnupg:create

--filesystem=xdg-run/gnupg:rw is sufficient. My problem is with the fact that a gpg-agent process that is launched in an isolated environment is exposed to the host system. Any host process accessing the socket during the time Claws-Mail is running, will interact with the isolated instance, instead of the host gpg-agent as would be expected.

cobratbq commented 4 years ago

To be clear, if gpg-agent socket is unavailable with --filesystem=xdg-run/gnupg:ro the result is that claws-mail will hang upon opening mail. Apparently the failure to access gnupg for writing causes this blocking situation. So, simply exposing the directory - whether gpg-agent is running or not - is not an option.

Erick555 commented 4 years ago

Unit gpg-agent.socket could not be found.

What distro do you use?

The problem with --filesystem=xdg-run/gnupg may be that this path doesn't exist when claws mail start so flatpak can't setup it inside sandbox. --filesystem=xdg-run/gnupg:create should fix that however we have to figure out how gpg-agent is started on your system.

Erick555 commented 4 years ago

BTW, you are testing this without claws-mail-wrapper.sh right?

cobratbq commented 4 years ago

What distro do you use?

Fedora Silverblue

The problem with --filesystem=xdg-run/gnupg may be that this path doesn't exist when claws mail start so flatpak can't setup it inside sandbox. --filesystem=xdg-run/gnupg:create should fix that however we have to figure out how gpg-agent is started on your system.

So, directory xdg-run/gnupg exists, but sockets inside do not because:

tmpfs          tmpfs  942M   40M  902M   5% /run/user/1000

Right now, gpg-agent is started when it is first needed by gpg. (Note that git will fail to discover the authentication key too, before gpg-agent is running. So this matches expectations.)

BTW, you are testing this without claws-mail-wrapper.sh right?

Yes, I try both actually.

Erick555 commented 4 years ago

It seems that fedora unlike Arch or Debian/Ubuntu doesn't ship systemd integration for gpg. On the latter sockets are permanently listening and trigger gpg-agent start when something calls for them.

Maybe there is no other way than manually starting gpg-agent to make it work on fedora then.

cobratbq commented 4 years ago

It seems that fedora unlike Arch or Debian/Ubuntu doesn't ship systemd integration for gpg. On the latter sockets are permanently listening and trigger gpg-agent start when something calls for them.

Thanks. I wasn't aware of this way of working in other distros. This helps.

Maybe there is no other way than manually starting gpg-agent to make it work on fedora then.

So far, only on-demand. I'll investigate a bit. I also have a "normal" Fedora installation. Let's see if that behaves differently.

I was thinking of trying to define the script as such that it would only start gpg-agent inside the app container, if no other instance is available. However, I cannot see how I can do this given that the mount-point xdg-run/gnupg is either there or it isn't. I may have to stick with the more conservative way-of-working for now, until there are more reliable base expectations for all systems.

Erick555 commented 4 years ago

As I understand when gpg-agent isn't running on host then xdg-run/gnupg will be empty (on fedora). You may pass --filesystem=xdg-run/gnupg and then check if it's empty. If yes then run gpg-agent in sandbox

cobratbq commented 4 years ago

If yes then run gpg-agent in sandbox

Sure, that works. I have seen this in practice for Claws-Mail. However, then you will have a containerized gpg-agent accessible from the host system. (Remember, xdg-run/gnupg is shared, so socket is accessible on host.) And any application on the host accessing gpg-agent will assume it will access the host gpg-agent. I'm worried that the containerized gpg-agent will be restrained to some extent, which may cause unexpected problems.

If you can determine/tell that that isn't going to be a problem, then sure, making xdg-run/gnugpg read-write is all we need to do to fix it.

Erick555 commented 4 years ago

Did you tested that if sockets are created by gpg-agent from sandbox then hosts apps call gpg-agent from sandbox?

cobratbq commented 4 years ago

Okay, so I'll produce a transcript to make sure we're not miscommunicating :-) I placed some comments between '()'.

$ ls /run/user/1000/gnupg/
(no result)
$ ps ax | grep gpg-agent
   5053 pts/1    S+     0:00 grep --color=auto gpg-agent
$ flatpak run --filesystem=xdg-run/gnupg org.claws_mail.Claws-Mail
(This did not work; did not seem to override correctly or I did something else wrong. At this point I switch to local dev set-up and run from 'build' directory to continue testing: change manifest to include --filesystem=xdg-run/gnupg, wrapper-script remains in-place/in-use. There are still no agents running on host.)
$ make run
(open encrypted mail to encourage 'gpg' to run, just in case)
$ ls /run/user/1000/gnupg/
S.gpg-agent  S.gpg-agent.browser  S.gpg-agent.extra  S.gpg-agent.ssh
$ gpg --card-status
gpg: WARNING: server 'gpg-agent' is older than us (2.2.17 < 2.2.18)
gpg: Note: Outdated servers may lack important security fixes.
gpg: Note: Use the command "gpgconf --kill all" to restart them.
gpg: WARNING: server 'scdaemon' is older than us (2.2.17 < 2.2.18)
gpg: Note: Outdated servers may lack important security fixes.
gpg: Note: Use the command "gpgconf --kill all" to restart them.
gpg: selecting card failed: No such device
gpg: OpenPGP card not available: No such device
(similarly, git will not find smartcard for authn)

So, according to my expectations - and this seems to illustrate as such - the sockets created by the "flatpak-gpg-agent" are now exposed to the host system. Host system apps detect running gpg-agent because they discover the open sockets. Try to communicate. Find out something is wrong.

This is the situation that I would like to avoid at all cost. Especially because it would be hard to debug what has happened exactly, with all of these "alternative binaries/versions" involved.

Erick555 commented 4 years ago

I understand that gpg --card-status was run on host, not in sandbox right?

I looked at gnupg docs and it seems only .extra and .ssh sockets could be moved to different place at runtime without touching main gpg-agent config. That leaves three potential solutions (and each one being a compromise):

  1. Run gpg-agent from sandbox and use separate --homedir. This means all settings (including keyrings) won't be shared between Claws-Mail gpg instance and host gpg.
  2. Run gpg-agent from sandbox and communicate users that using host gpg at the same time Claws-Mail is running isn't supported.
  3. Communicate users that they should manually start gpg-agent (at least on fedora) before they can use gpg functionality in Claws-Mail
cobratbq commented 4 years ago

I understand that gpg --card-status was run on host, not in sandbox right?

Correct

I looked at gnupg docs and it seems only .extra and .ssh sockets could be moved to different place at runtime without touching main gpg-agent config.

I don't recall having seen any option to change the default socket, no sure there was some weird syntax to redirect from within $GNUPGHOME indeed. I'm really not a fan of this option.

  1. Run gpg-agent from sandbox and use separate --homedir. This means all settings (including keyrings) won't be shared between Claws-Mail gpg instance and host gpg.

Indeed, which is basically not an option, because how would you explain where to put keys into the app-instance. It's either going to be weird $GNUPGHOME locations and too complicated to be intuitive. And then there's the matter of having to duplicate secret key material.

  1. Run gpg-agent from sandbox and communicate users that using host gpg at the same time Claws-Mail is running isn't supported.

This is a viable option. Even if they do not discover this at first use, they can discover the message once they read info on the flatpak distro because they encounter weird behavior regarding gpg.

  1. Communicate users that they should manually start gpg-agent (at least on fedora) before they can use gpg functionality in Claws-Mail

This seems the most viable option to me. I know that gpg-agent exits with non-zero exit code in case no agent is running yet, so maybe I can display a message of sorts to alert the user to this situation.

To be continued ...

cobratbq commented 4 years ago

Thought about this some more. I thought of 2 other options, but they fail due to missing functionality:

  1. Map xdg-run/gnupg on host to xdg-run/gnupg-host in application. Then check if socket exists, if so link to xdg-run/gnupg in application. However, there is no way to define the destination location in the application container.
  2. Mount --filesystem=xdg-run/gnupg with sort of option indicating an overlay over the host content, such that files/sockets created on that location inside the app container will not pass through to the host. However, no such "mount-option" is available.

Still not happy with the available options ...