ProtonMail Bridge not working anymore in 4.1 with Qrexec


I’m trying to get a ProtonMail Bridge setup working in Qubes 4.1. It worked very well in 4.0 but somehow I cannot get the Qrexec policies right.

This is what I did in 4.0 (based on what I read in the Qubes documentation):

  • Qube “protonmail” with ProtonMail Bridge, which essentiall opens up a mail server on ports 1143 and 1025
  • Qube “thunderbird” with Thunderbird, which will be connecting to the mailserver on “protonmail”
  • Adding those two lines in Qube “thunderbird” in /rw/config/rc.local:
    • qvm-connect-tcp 1143:@default:1143
    • qvm-connect-tcp 1143:@default:1025
  • Adding this line in Dom0 /etc/qubes.rpc/policy/qubes.ConnectTCP:
    • thunderbird @default allow,target=protonmail

I’m trying the same in Qubes 4.1 now, just with the updated Qrexec system, based what I’ve read here. So, the last part looks like this instead:

  • Adding this line in Dom0 /etc/qubes/policy.d/30-user.policy:
    • qubes.ConnectTCP +1143 thunderbird @default allow,target=protonmail
    • qubes.ConnectTCP +1025 thunderbird @default allow,target=protonmail

My guess is that I’m doing something wrong with that qrexec policies in Dom0. I noticed that those new policies are somehow killing the copy/paste across VMs. When they are active, the copy/paste is not working. When I remove them it is working again.

Any ideas?

Strange but interesting. I want to give a try to “split-everything” “socketable” (smartcard, keepassxc, whatever) and possibly protonmail, will tell you the results.

1 Like

The new syntax requires a space after the action (allow); you have a comma.

Thanks a lot, @icequbes1! Replacing the comma with a space works:

  • qubes.ConnectTCP +1143 thunderbird @default allow target=protonmail
  • qubes.ConnectTCP +1025 thunderbird @default allow target=protonmail

@adw / @marmarek: Maybe it makes sense to correct the example in this news article:

This line…

# Example of policy: qubes.ConnectTCP +22 mytcp-client @default allow,target=mytcp-server

… should look like this, it seems:

# Example of policy: qubes.ConnectTCP +22 mytcp-client @default allow target=mytcp-server

Well, that syntax was correct at the time that post was published. Even if the syntax was subsequently changed, I’m not sure it makes sense to “retcon” that change back into an old post, as that would make the post inaccurate relative to the state of the software at the time at which it was published. If you think about it, taking this to its logical conclusion would require us to constantly update all old posts as the system changes, which wouldn’t really make sense. It’s a post with a specific date, so it’s supposed to be accurate as of that date. It’s not a documentation page that’s supposed to be accurate as of a specific release or as of the present time. If we’re missing a documentation page for this and just leaning on the old post in the absence of proper documentation, then please open an issue to add the missing documentation (or contribute it).

There was a typo in the news article, but it was only in a commented line that came from the default config file. That was recently addressed at Syntax error in 90-default.policy sample code · Issue #6945 · QubesOS/qubes-issues · GitHub.

However, do note that the rest of the article clearly indicates a space character is the proper syntax. No judgment, but I can fully understand why the sample line would be used when trying to simply make things work. I’d vote for updating the article only because AFAIK, this article is the de facto documentation for 4.1 syntax.

Yes, I fully agree with that. However this is a different situation, where this comma was wrong even at the time of posting the article (as @icequbes1 already indicated).

The article is liked in the 4.1 RC1 news article, saying in the line above that it explains the new features in depth. Seeing this, I also felt that this is the defacto documentation of this new syntax.

Considering the importance of this change in Qrexec and the prominent placement of this article in the recent announcements, I guess it would help also other users if this typo would be corrected (e.g. by correcting it and adding something like “Edit: Typo corrected in the example of the ConnectTCP policy” to the article).

I surely would not expect that every old news article gets updated whenever a feature/syntax changes later :wink:

Oh, well of course that’s a different story! Typo fixed:

In the future, please feel free to submit typo fix PRs yourself. Anyone can do it!

As I said above:

I don’t think it’s necessary to add this to the body content of an article just because a typo was fixed. That’s exactly why we have the Git commit log.

1 Like