Tails

#1 Updated by intrigeri 2017-03-18 14:36:02

• Assignee changed from intrigeri to anonym

keyserver --hosttable now lists the known keyservers only after dirmngr has actually tried to connect to them.

So moving the GnuPG uses the configured keyserver step to after I fetch the "10CC5BC7" OpenPGP key using the GnuPG CLI should be enough to fix that, and this will give us additional confidence that dirmngr is not only configured to use the right keyserver, but also that it actually uses it (and then the step should probably be renamed accordingly).

#2 Updated by intrigeri 2017-03-18 15:30:24

• Type of work changed from Research to Code

#3 Updated by anonym 2017-03-18 15:53:24

• File 0001-Test-suite-verifry-that-dirmngr-used-the-configured-.patch added
• Assignee changed from anonym to intrigeri
• QA Check set to Info Needed

I added a step GnuPG's dirmngr uses the configured keyserver (see attached patch) that just fails with:

      Command failed: gpg-connect-agent --dirmngr "keyserver --hosttable" /bye
      error code: 1
      stderr: gpg-connect-agent: no running Dirmngr - starting '/usr/bin/dirmngr'
      gpg-connect-agent: waiting for the dirmngr to come up ... (5s)
      gpg-connect-agent: waiting for the dirmngr to come up ... (4s)
      gpg-connect-agent: waiting for the dirmngr to come up ... (3s)
      gpg-connect-agent: waiting for the dirmngr to come up ... (2s)
      gpg-connect-agent: waiting for the dirmngr to come up ... (1s)
      gpg-connect-agent: connecting dirmngr at '/run/user/0/gnupg/S.dirmngr' failed: IPC connect call failed
      gpg-connect-agent: error sending standard options: No dirmngr
      .
      <false> is not true. (ExecutionFailedInVM)
      ./features/support/helpers/vm_helper.rb:438:in `rescue in execute_successfully'
      ./features/support/helpers/vm_helper.rb:435:in `execute_successfully'
      ./features/step_definitions/torified_gnupg.rb:252:in `/^GnuPG's dirmngr uses the configured keyserver$/'
      features/torified_gnupg.feature:18:in `And GnuPG's dirmngr uses the configured keyserver'

I don’t get why dirmngr is so short-lived. Perhaps it’s due to something in the remote shell’s environment? Any ideas?

#4 Updated by intrigeri 2017-03-20 11:56:41

• Assignee changed from intrigeri to anonym

> I don’t get why dirmngr is so short-lived. Perhaps it’s due to something in the remote shell’s environment? Any ideas?

What if you run this as the amnesia user, instead of root?
Also, the remote shell might lack some envvars like GPG_AGENT_INFO.

#5 Updated by anonym 2017-04-20 12:11:23

• Status changed from Confirmed to Fix committed
• Assignee deleted (anonym)
• % Done changed from 0 to 100
• QA Check changed from Info Needed to Pass

intrigeri wrote:
> > I don’t get why dirmngr is so short-lived. Perhaps it’s due to something in the remote shell’s environment? Any ideas?
>
> What if you run this as the amnesia user, instead of root?

That works! Of course, root’s attempt will be blocked by the firewall. So, this should be fixed as of commit:f31e2b823607ca6138e1437d5b02e47969cb4e03. Closing!

#6 Updated by anonym 2017-04-20 13:21:27

• Status changed from Fix committed to In Progress

Applied in changeset commit:f31e2b823607ca6138e1437d5b02e47969cb4e03.

#8 Updated by intrigeri 2017-06-04 14:18:19

• Assignee set to anonym

#9 Updated by anonym 2017-06-12 16:07:23

• Target version changed from Tails_3.0 to Tails_3.1

#10 Updated by anonym 2017-06-29 13:32:41

• blocks Feature #13239: Core work 2017Q3: Test suite maintenance added

#11 Updated by anonym 2017-07-06 14:15:06

• Target version changed from Tails_3.1 to Tails_3.2

#12 Updated by anonym 2017-09-07 13:22:33

• Status changed from In Progress to Resolved
• Assignee deleted (anonym)

This was actually solved in Tails 3.0.