Can't open my tombs anymore: get stuck at get_lukskey()

[ghost]

Hi,

Command I use:

tomb open Data/secret.tomb -k ~/.secrets/secret.tomb.key -D

Result:

tomb [D] Identified caller: laurenth (1000:100)
tomb [D] Tomb command: open Data/secret.tomb
tomb [D] Caller: uid[1000], gid[100], tty[/dev/pts/1].
tomb [D] Temporary directory: /tmp/zsh
tomb  .  Commanded to open tomb Data/secret.tomb
tomb  .  An active swap partition is detected...
tomb (*) All your swaps are belong to crypt.  Good.
tomb [D] is_valid_tomb Data/secret.tomb
tomb  .  Un fichier de tombe valide a été trouvé à : Data/secret.tomb
tomb [D] Tomb found: Data/secret.tomb
tomb [D] load_key argument: /home/laurenth/.secrets/secret.tomb.key
tomb [D] load_key: /home/laurenth/.secrets/secret.tomb.key
tomb [D] is_valid_key
tomb  .  La clé est valide.
tomb  .  Le point de montage n'a pas été précisé, nous utilisons donc /media/secret.tomb
tomb (*) Opening secret.tomb on /media/secret.tomb
tomb  .  Cette tombe est un dispositif chiffré LUKS valide.
tomb  .  Algorithme de chiffrement "aes" en mode "xts-plain64:sha256" et la fonction de hachage "sha1".
tomb [D] dev mapper device: tomb.secret.1435658282.loop1
tomb [D] Tomb key: /home/laurenth/.secrets/secret.tomb.key
tomb [D] Tomb name: secret (to be engraved)
tomb  .  Un mot de passe est nécessaire pour utiliser la clé /home/laurenth/.secrets/secret.tomb.key
tomb [D] get_lukskey

and the tomb is not opened.

Interesting thing (the password is valid), with:

unset LANG; tomb open Data/secret.tomb -k ~/.secrets/secret.tomb.key -D

I get:

...
tomb  .  A password is required to use key /home/laurenth/.secrets/secret.tomb.key
tomb [W] Pinentry error: syntax
tomb [W] User aborted password dialog.
tomb [E] No valid password supplied.

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
• cryptsetup 1.6.7
• pinentry 0.9.1
• gnupg 2.1.5

Same symptoms on all my tombs. There all were created with tomb 2.0.

Thanks for helping :)

[jaromil]

no idea yet, but quick observation: this problem looks like related to pinentry.

[arthaud]

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.

[jaromil]

Very well spotted Arthaud! Many thanks!

I will ask ZSH devs about this one, they are usually well responsive.

[jaromil]

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

[ghost]

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.

[jaromil]

I tried several ways, but could not reproduce it yet. Can you investigate this further? is anyone able to reproduce this problem?

[arthaud]

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 ;)

[ghost]

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 ?

[jaromil]

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.

[jaromil]

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}

[jaromil]

This commit may help you looking deeper e8ca2998b92fd929351ff58d

[Narrat]

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

[jaromil]

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.

[jaromil]

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.

[cyphar]

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.

[jaromil]

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