Bug #11922

Encryption error when sending WhisperBack report in Stretch

Added by sajolida 2016-11-15 21:02:54 . Updated 2016-11-16 16:15:45 .

Status:
Resolved
Priority:
Normal
Assignee:
intrigeri
Category:
Target version:
Tails_3.0
Start date:
2016-11-15
Due date:
% Done:

100%

Feature Branch:
whisperback:master
Type of work:
Code
Blueprint:

Starter:
Affected tool:
WhisperBack
Deliverable for:

Description

If I try to send a WhisperBack report from Tails Stretch I get the following error message:

An error occured during encyption.

Subtasks

History

#1 Updated by intrigeri 2016-11-16 09:49:47

  • Status changed from New to Confirmed
  • Assignee changed from intrigeri to alant

#2 Updated by alant 2016-11-16 11:39:52

  • Status changed from Confirmed to In Progress

I reproduced this issue with latest Stretch iso. Manual encryption with gpg --no-default-keyring --keyring /usr/share/keyrings/tails-keyring.gpg --armor --recipient 1F56EDD30741048035DAC1C5EC57B56EF0C43132 --always-trust --encrypt works, but python3-gnupg keeps on answering:

>>> import gnupg
>>> gpg = gnupg.GPG(keyring="/usr/share/keyrings/tails-keyring.gpg")
>>> crypt = gpg.encrypt("test", "1F56EDD30741048035DAC1C5EC57B56EF0C43132", always_trust=True)
>>> crypt.status
'invalid recipient'

#3 Updated by intrigeri 2016-11-16 12:13:44

> Manual encryption with
> gpg --no-default-keyring --keyring > /usr/share/keyrings/tails-keyring.gpg --armor --recipient > 1F56EDD30741048035DAC1C5EC57B56EF0C43132 --always-trust --encrypt
> works,

This is GnuPG v2. What happens if you use /usr/bin/gpg1 instead?

> but
> python3-gnupg keeps on answering:

>

>>>> import gnupg
>>>> gpg = gnupg.GPG(keyring="/usr/share/keyrings/tails-keyring.gpg")
>>>> crypt = gpg.encrypt("test", "1F56EDD30741048035DAC1C5EC57B56EF0C43132", always_trust=True)
>>>> crypt.status
> 'invalid recipient'
>

This is GnuPG v1.

What happens if you specify the encryption subkey instead of the master key?

#4 Updated by intrigeri 2016-11-16 12:21:07

Looks like when we initialize the keyring in config/chroot_local-includes/lib/live/config/2000-import-gnupg-key, GnuPG (v2) creates a keyring in its new format (.kbx), that GnuPG v1 doesn’t know about. I bet this explains why python3-gnupg (that uses GnuPG v1) can’t do its job.

#5 Updated by alant 2016-11-16 13:56:00

Explicitely passing gpgbinary=/usr/bin/gpg to python3-gnupg fixes the issue.

#6 Updated by alant 2016-11-16 13:57:02

  • Type of work changed from Research to Code

#7 Updated by alant 2016-11-16 14:18:59

  • Assignee changed from alant to intrigeri
  • QA Check set to Ready for QA
  • Feature Branch set to whisperback:master

This is fixed in whisperback’s master. Tested by locally building a package, it works under stable and stretch.

#8 Updated by intrigeri 2016-11-16 16:09:21

  • % Done changed from 0 to 60

Looks good to me, building a package, will upload to devel + feature-stretch.

#9 Updated by intrigeri 2016-11-16 16:15:45

  • Status changed from In Progress to Resolved
  • % Done changed from 60 to 100
  • QA Check changed from Ready for QA to Pass

Uploaded WhisperBack 1.7.7 to devel + feature-stretch.