Project

General

Profile

Bug #11922

Encryption error when sending WhisperBack report in Stretch

Added by sajolida about 3 years ago. Updated about 3 years ago.

Status:
Resolved
Priority:
Normal
Assignee:
Category:
-
Target version:
Start date:
11/15/2016
Due date:
% Done:

100%

Feature Branch:
whisperback:master
Type of work:
Code
Blueprint:
Starter:
Affected tool:
WhisperBack

Description

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

An error occured during encyption.

History

#1 Updated by intrigeri about 3 years ago

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

#2 Updated by alant about 3 years ago

  • 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 about 3 years ago

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 about 3 years ago

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 about 3 years ago

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

#6 Updated by alant about 3 years ago

  • Type of work changed from Research to Code

#7 Updated by alant about 3 years ago

  • 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 about 3 years ago

  • % Done changed from 0 to 60

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

#9 Updated by intrigeri about 3 years ago

  • 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.

Also available in: Atom PDF