Closed ghost closed 9 years ago
no idea yet, but quick observation: this problem looks like related to pinentry.
Actually, I had the same issue 2 weeks ago. That's very tricky.. it only happens with French users.. The problem is in gpg_decrypt():
TOMBSECRET=`print - "$gpgpass" | \
gpg --batch --passphrase-fd 0 --no-tty --no-options \
--status-fd 2 --no-mdc-warning --no-permission-warning \
--no-secmem-warning` 2>&1 | read -r -d'\n' gpgstatus
unset gpgpass
ret=1
[[ "${gpgstatus}" =~ "DECRYPTION_OKAY" ]] && { ret=0 }
With a french computer, we get something like:
gpgpass="gpg: données chiffrées avec AES256
[GNUPG:] NEED_PASSPHRASE_SYM * * *
gpg: chiffré avec 1 phrase secrète
[GNUPG:] BEGIN_DECRYPTION
[GNUPG:] DECRYPTION_INFO * *
[GNUPG:] PLAINTEXT ** ********
[GNUPG:] PLAINTEXT_LENGTH ***
[GNUPG:] DECRYPTION_OKAY
[GNUPG:] GOODMDC
[GNUPG:] END_DECRYPTION"
And guess what, there is a non-breaking space for no reason between "1" and "phrase". This non-breaking space makes zsh freeze at that line:
[[ "${gpgstatus}" =~ "DECRYPTION_OKAY" ]] && { ret=0 }
Thus it's probably a bug in zsh. Try [[ " X" =~ "X" ]]
(where the first character in " X" is a non-breaking space) in zsh, you should get stuck.. Ctrl+C doesn't even work.
Very well spotted Arthaud! Many thanks!
I will ask ZSH devs about this one, they are usually well responsive.
ZSh developers are so cool that they have seen and fixed this bug already less than a month ago: http://www.zsh.org/mla/users/2015/msg00654.html
I've filed the bug for GnuPG here https://bugs.gnupg.org/gnupg/issue2027
Sorry, but this is not over :(
unset LANG; tomb forge secret.tomb.key -D
gives:
tomb (*) Choose the password of your key: secret.tomb.key
tomb . (You can also change it later using 'tomb passwd'.)
tomb [W] Pinentry error: syntax
tomb [E] User aborted.
Same error when I try to open an existing (and locked) tomb.
I tried several ways, but could not reproduce it yet. Can you investigate this further? is anyone able to reproduce this problem?
It works for me, with almost the same environment:
Archlinux up-to-date Linux ****\ 4.0.7-2-ARCH #1 SMP PREEMPT Tue Jun 30 07:50:21 UTC 2015 x86_64 GNU/Linux tomb 2.0.1 cryptsetup 1.6.7 pinentry 0.9.1 gnupg 2.1.5 LANG="fr_FR.UTF-8"
I'm using aur/tomb-git, which package are you using?
NB: I'm the one who reported the bug on the zsh mailing one month ago ;)
Quick observation, I can go further if I use LANG=en_US.utf8
but strangely the output is translated in french (!?!). I'll provide full details this afternoon.
EDIT. It works fine with tomb-git 2.0.1.r51.g55d3263. Does it still worth investigating for the old version ?
That seems to be an hash of Arch packaging, it does not corresponds to the git version so I cannot help, hope you figure it out. I cannot reproduce it on any system so perhaps the problem is really about something else in your setup. Try printing out the commands fed into pinentry they may provide hints.
BTW you mentioned this occurs when you do unset LANG
, consider that for Tomb that is equivalent to LANG=C
see at L:377
# make sure LANG is set, default to C
LANG=${LANG:-C}
This commit may help you looking deeper e8ca2998b92fd929351ff58d
That seems to be an hash of Arch packaging
Nope. Users a responsible for if it's an AUR package. They built it themselves. And the $pkgver is set for -git packages like: Latest tag (if available) + rev count since last tag(rXX) + commit hash (gYYYYYYYY) So he built a package on top of this https://github.com/dyne/Tomb/commit/55d3263cacf0509a9345855508d6422028ad52c9
Edit: https://github.com/Narrat/PKGBuilds/blob/master/tomb-git/PKGBUILD#L26 They're just recipes, and normally Arch has the policy to not tamper with upstream sources. So this will get latest checkout and built on top. Although the g in front of the hash can be irritating
ACK, thanks for explaining! I'll standby for progress from Laurenth however I sort of consider this bug fixed with some minor doubts regarding his setup. If you get stuck with some errors so that you cannot access tombs, always refer to the code snippets in the README documenting how to open and close tombs without using the tomb script.
No follow up, assuming this is fixed, please re-open only if there are more details on the last blurry issue raised after the fix.
This happens to me occasionally, and I don't use French. The weird thing is that this worked for quite a while and only recently stopped working then just started working again. I also figured that the error is related to pinentry (but replacing pinentry with something like systemd-ask-password
still doesn't work). If it happens again, I'll update with the error message I get.
/me looks at :put_litter_in_its_place: systemd :put_litter_in_its_place: and shivers :scream_cat:
thanks for signaling, indeed we need to have an error message about this one, perhaps also look into system logs and dmesg just to make sure.
Hi,
Command I use:
Result:
and the tomb is not opened.
Interesting thing (the password is valid), with:
I get:
I use Archlinux and:
Linux dagobah 4.0.6-1-ARCH #1 SMP PREEMPT Tue Jun 23 14:25:08 CEST 2015 x86_64 GNU/Linux
Same symptoms on all my tombs. There all were created with tomb 2.0.
Thanks for helping :)