SplitGPG "Request refused"

User Support
1

Hi,

i had split-gpg with subkeys set up a while a go but now it stopped working. (Thunderbird wont start for whatever reason). After troubleshooting it a few minutes i figured, that it will be quicker to just set up a new work qube.

I followed this instruction for the work-gpg and work qubes and it worked the first time.

But now i get a “Request refused” when trying to qubes-gpg-client -K on both work and newwork qubes with my work-gpg and newwork-gpg qubes. It does not ask what qube to connect to, like it should.

I also changed the /etc/qubes-rpc/policy/qubes.Gpg but this should not be the problem as it is only an ease of use configuration.

gpg -K works well on both my old work-gpg and my newwork-gpg.

man qubes-gpg-client wasn’t really helpful for me.

Any ideas where i could gone wrong/how to troubleshoot this?

In case this is important: the work and work-gpg that failed where restored from a backup of another qube installation but on the same hardware and ran after restoring them. qubes-gpg-split-dom0 is installed.

Also i think that the problem with Thunderbird can be reduced to a problem of split-gpg as the pre Thunderbird prompt “You sure you want to let this qube access your gpg qube?” also did not show up.

Thanks for your help!

2

I know you said you followed the instructions, but let’s double-check:
did you create the /rw/config/gpg-split-domain file? What is it’s contents?

Are you sure qubes-gpg-split is installed in both qubes?

/Sven

3

Thanks for your answer!

I made sure, that qubes-gpg-clientis installed on work-gpg and work.

Still, it only gives me a Request refused.

The content of the /rw/config/gpg-split-domain in work is work-gpg so it looks fine to me. Interessting enough, it stopped working from one day to the other with no changes to any of those qubes made.

4

I made a backup of the work and work-gpg qube and restored it on another machine of mine. It is working there, so it seems, that something is broken with dom0 i guess?

5

Still, it only gives me a Request refused.

The content of the /rw/config/gpg-split-domain in work is
work-gpg so it looks fine to me. Interessting enough, it stopped
working from one day to the other with no changes to any of those
qubes made.

It is unlikely to be your issue, but I have seen this yesterday when the
permissions on /rw/config/gpg-split-domain where user only.

6

From my experience with split GPG and other RPC policies, a “request refused” is related with the policy file (/etc/qubes-rpc/policy/qubes.Gpg). Also, what do you mean by “an easy of use configuration”?

7

@deeplow i meant the export GNUPG_HOME…
So the content of the qubes.GPG
is

$anyvm  $anyvm  ask
@work  @work  ask,default_target=work-gpg

@Sven: The permissions on the file are -rw-rw-r-- so that should be fine.

8

Not sure if this is the problem, but you’ll at least want to have the lines switched. As the docs indicate:

Now, the whole policy file is parsed from top to bottom. As soon as a rule is found that matches the action being evaluated, parsing stops.

Since your second one is more restrictive than the second one, the second never ends up being evaluated.

9

@work @work ask,default_target=work-gpg ``` [/quote]

I think what you want is:

@work work-gpg allow

You will still get the dialog from work-gpg if you want to allow access.

Having @work be the source and the target makes little sense to me. If
you have more than one vault you could use:

@work $anyvm ask,default_target=work-gpg

Since your second one is more restrictive than the second one, the
second never ends up being evaluated.

… and that too.

1 Like
10

I wasn’t able to repair this issue so i opted for a simple reinstall (i had some other issues).

Something of note, that most people know but i didn’t regarding your comment:

As indicated in the documentation, one should add the @work work-gpg allow in front of the ask rule. Of course.