RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 676034 - volume_key --save: - Error creating `packet': GPGME: Bad passphrase
Summary: volume_key --save: - Error creating `packet': GPGME: Bad passphrase
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: doc-Technical_Notes
Version: 6.1
Hardware: Unspecified
OS: Unspecified
high
high
Target Milestone: rc
: ---
Assignee: Ryan Lerch
QA Contact: ecs-bugs
URL:
Whiteboard:
Depends On: 637902
Blocks:
TreeView+ depends on / blocked
 
Reported: 2011-02-08 16:58 UTC by Miroslav Vadkerti
Modified: 2011-05-27 05:31 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
The DISPLAY environment variable was set but no graphical - Qt or GTK backend of the pinentry was installed (packages pinentry-gtk or pinentry-qt). Due to this issue, the volume_key command printed "volume_key: Error creating `packet': GPGME: Bad passphrase" although the user supplied the correct credentials. This workaround unsets the environment variable DISPLAY. Now, the volume_key works as expected. Workaround command: # unset DISPLAY
Clone Of:
Environment:
Last Closed: 2011-05-27 05:31:07 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)

Description Miroslav Vadkerti 2011-02-08 16:58:42 UTC 
Description of problem:
When I follow these repro steps which we used for testing volume_key in EL6, I cannot save escrow packet:

# dd if=/dev/urandom of=testpartition bs=1M count=10
# losetup /dev/loop0 testpartition
# cryptsetup luksFormat /dev/loop0
(enter password)
# cryptsetup luksDump /dev/loop0
LUKS header information for /dev/loop0
Version:       	1
Cipher name:   	aes
Cipher mode:   	cbc-essiv:sha256
Hash spec:     	sha1
Payload offset:	4096
MK bits:       	256
MK digest:     	90 d0 d8 bd 49 40 eb c3 fa 3d 00 44 ea 59 37 36 c9 d1 e6 99 
MK salt:       	a6 e0 c8 84 24 5f d4 0b f8 dc 41 c9 9e 7f 1f 3d 
               	c8 a9 67 b9 c4 ad 57 31 90 d1 ea 75 b1 49 fd 28 
MK iterations: 	33000
UUID:          	f5d9431d-2428-4ab6-8e11-c4228a561249

Key Slot 0: ENABLED
	Iterations:         	132130
	Salt:               	44 9b c1 37 69 eb d2 2c 98 7f b0 70 e4 5c ff 8d 
	                      	68 ac 60 02 5b bb 82 83 a3 14 db 05 ad 30 80 e6 
	Key material offset:	8
	AF stripes:            	4000
Key Slot 1: DISABLED
Key Slot 2: DISABLED
Key Slot 3: DISABLED
Key Slot 4: DISABLED
Key Slot 5: DISABLED
Key Slot 6: DISABLED
Key Slot 7: DISABLED

# volume_key --save /dev/loop0 -o packet  
Passphrase for `/dev/loop0': 
New packet passphrase: 
Repeat new packet passphrase: 
volume_key: Error creating `packet': GPGME: Bad passphrase
(I used strong password)

Version-Release number of selected component (if applicable):
gpgme-1.1.8-3.el6.x86_64
volume_key-0.3.1-5.el6.x86_64

How reproducible:
100%

Steps to Reproduce:
see description
  
Actual results:
volume_key: Error creating `packet': GPGME: Bad passphrase

Expected results:
Packet is saved without issues

Additional info:
Tested on x86_64 architecture.
Comment 2 Miloslav Trmač 2011-02-10 15:48:11 UTC 
I have seen similar behavior with volume_key-0.3.1-3 when pinentry-gtk was not installed.

In particular, without X there was be a full-screen PIN dialog and everything worked fine; in gnome-terminal volume_key failed as described as above, but installing pinentry-gtk fixed this.

Could you check if you see the same behavior, please?
Comment 3 Miroslav Vadkerti 2011-02-11 12:53:17 UTC 
I can confirm that installing pinentry-gtk fixes this issue. Thanks very much. Should volume_key or gpgme have this package as dependency in this case?
Comment 4 Miloslav Trmač 2011-02-11 13:13:54 UTC 
Neither - both are supposed to provide a passphrase without any user interaction: this bug is essentially another manifestation of #637902.

Perhaps gnupg2 should add the pinentry-gtk dependency, I'm not sure.
Comment 5 Miroslav Vadkerti 2011-02-11 13:55:00 UTC 
Tomas, please which package actually calls pinentry-gtk binary? That one should include it as a dependency.
Comment 6 Tomas Mraz 2011-02-11 14:26:58 UTC 
No, I don't think that there should be a hard dependence on pinentry-gtk. This package should be in comps default so it is normally installed on systems with X/gtk. But it should not be pulled as a hard dependency of gnupg2.
Comment 7 Miroslav Vadkerti 2011-02-11 14:47:28 UTC 
But if I have a server installation without X/gtk packages installed (which would pull in pinentry-gtk) and I want to use volume_key -> how should I know I need to install pinentry-gtk? If volume_key won't work without pinentry_gtk it should require it or should print a reasonable error message why passphrase cannot be entered.
Comment 8 Tomas Mraz 2011-02-11 15:00:24 UTC 
Maybe I misunderstood the bug - do you see the problem happen only when you have the DISPLAY environment variable set?
Comment 9 Tomas Mraz 2011-02-11 15:29:13 UTC 
So the situation is that when pinentry-gtk is not existing in the system and the DISPLAY is set the pinentry script will fail. It would be probably more appropriate to run pinentry-ncurses in such situation, perhaps at least in case a tty is available.
Comment 10 Stanislav Ochotnicky 2011-02-14 09:15:49 UTC 
Hmm, if you have server installation without X, why is your DISPLAY set? I am guessing remote ssh with X redirect? That means you must have xauth installed on the machine so it's not completely X-less.

On pinentry side there is simple workaround for this: unset DISPLAY before using anything that requires pinentry when you don't have graphical pinentry subpackage installed.

I'll see about the rest of problems
Comment 11 Stanislav Ochotnicky 2011-02-14 09:57:01 UTC 
OK, there seems to be problem with running gpg/pinentry as root. Therefore for volume-key to work one needs to run gpg-agent as a normal user and then supply GPG_AGENT_INFO in root shell. I was able to succesfully execute "volume_key --save /dev/loop0 -o packet" like this.
Comment 12 Miroslav Vadkerti 2011-02-14 10:31:37 UTC 
Thanks for the comments, should these workarounds be documented somewhere?
Comment 14 Stanislav Ochotnicky 2011-02-14 16:17:53 UTC 
I added technical note explaining both problems and workarounds.
Comment 15 Stanislav Ochotnicky 2011-02-14 16:17:53 UTC 
    Technical note added. If any revisions are required, please edit the "Technical Notes" field
    accordingly. All revisions will be proofread by the Engineering Content Services team.
    
    New Contents:
If no graphical (-qt or -gtk) pinentry is installed then DISPLAY has to be unset (no X forwarding has to be active). Otherwise pinentry assumes existence of gtk or qt backends and doesn't fail gracefully. 

Additionally pinentry-ncurses fails if current tty is owned by different user as the one running pinentry. This happens for example when users does "su -" after logging in as normal user. The /dev/pts/XX file is not chown-ed to root and therefore pinentry-ncurses fails. If you want to run pinentry after doing "su -", you need to chown current pts to root.
Comment 16 Miloslav Trmač 2011-02-14 18:16:18 UTC 
(In reply to comment #15)
> Additionally pinentry-ncurses fails if current tty is owned by different user
> as the one running pinentry. This happens for example when users does "su -"
> after logging in as normal user. The /dev/pts/XX file is not chown-ed to root
> and therefore pinentry-ncurses fails. If you want to run pinentry after doing
> "su -", you need to chown current pts to root.
Won't chowning the TTY break the user's session after exiting from "su"?
Comment 17 Miroslav Vadkerti 2011-02-15 15:45:12 UTC 
So after sochotni investigation there is a bug in pinetry and the issue will be separately tracked by bug 677665. I removed the workaround from technical notes and I'm contacting content services to help me adding this to GSS knowledge base.
Comment 18 Miroslav Vadkerti 2011-02-15 15:45:12 UTC 
    Technical note updated. If any revisions are required, please edit the "Technical Notes" field
    accordingly. All revisions will be proofread by the Engineering Content Services team.
    
    Diffed Contents:
@@ -1,3 +1 @@
-If no graphical (-qt or -gtk) pinentry is installed then DISPLAY has to be unset (no X forwarding has to be active). Otherwise pinentry assumes existence of gtk or qt backends and doesn't fail gracefully. 
+If no graphical (-qt or -gtk) pinentry is installed then DISPLAY has to be unset (no X forwarding has to be active). Otherwise pinentry assumes existence of gtk or qt backends and doesn't fail gracefully.-
-Additionally pinentry-ncurses fails if current tty is owned by different user as the one running pinentry. This happens for example when users does "su -" after logging in as normal user. The /dev/pts/XX file is not chown-ed to root and therefore pinentry-ncurses fails. If you want to run pinentry after doing "su -", you need to chown current pts to root.
Comment 19 Miroslav Vadkerti 2011-02-15 16:43:50 UTC 
    Technical note updated. If any revisions are required, please edit the "Technical Notes" field
    accordingly. All revisions will be proofread by the Engineering Content Services team.
    
    Diffed Contents:
@@ -1 +1,4 @@
-If no graphical (-qt or -gtk) pinentry is installed then DISPLAY has to be unset (no X forwarding has to be active). Otherwise pinentry assumes existence of gtk or qt backends and doesn't fail gracefully.+The DISPLAY environment variable was set but no graphical - Qt or GTK backend of the pinentry was installed (pinentry-gtk or pinentry-qt). Due to this issue, the volume_key command printed "volume_key: Error creating `packet': GPGME: Bad passphrase" although the user supplied the correct credentials. This workaround unsets the environment variable DISPLAY. Now, the volume_key works as expected.
+
+Workaround command:
+# unset DISPLAY
Comment 20 Miroslav Vadkerti 2011-02-15 16:45:04 UTC 
    Technical note updated. If any revisions are required, please edit the "Technical Notes" field
    accordingly. All revisions will be proofread by the Engineering Content Services team.
    
    Diffed Contents:
@@ -1,4 +1,4 @@
-The DISPLAY environment variable was set but no graphical - Qt or GTK backend of the pinentry was installed (pinentry-gtk or pinentry-qt). Due to this issue, the volume_key command printed "volume_key: Error creating `packet': GPGME: Bad passphrase" although the user supplied the correct credentials. This workaround unsets the environment variable DISPLAY. Now, the volume_key works as expected.
+The DISPLAY environment variable was set but no graphical - Qt or GTK backend of the pinentry was installed (packages pinentry-gtk or pinentry-qt). Due to this issue, the volume_key command printed "volume_key: Error creating `packet': GPGME: Bad passphrase" although the user supplied the correct credentials. This workaround unsets the environment variable DISPLAY. Now, the volume_key works as expected.
 
 Workaround command:
 # unset DISPLAY
Comment 21 Stanislav Ochotnicky 2011-02-23 16:40:06 UTC 
Since this is not really a pinentry bug, just configuration error I am reassigning to doc team. This problem should probably be mentioned in one part of technical notes.
Comment 22 Jaromir Hradilek 2011-05-19 14:14:05 UTC 
The Deployment Guide for Red Hat Enterprise Linux 6 does not document volume_key. Moving to the Storage Administration Guide.
Comment 23 Jacquelynn East 2011-05-27 04:19:10 UTC 
Storage Admin doesn't document this. Moving to Technical Notes as per comment 21
Note You need to log in before you can comment on or make changes to this bug.