GNU bug report logs - #43704
26.1: gpg error on passphrase typo

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 43704 in the body.
You can then email your comments to 43704 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Boruch Baum <boruch_baum <at> gmx.com>
To: Emacs Bug Reporting <bug-gnu-emacs <at> gnu.org>
Subject: 26.1: gpg error on passphrase typo
Date: Tue, 29 Sep 2020 09:16:35 -0400

When making a mistake typing a gpg passphrase, an 'error' is generated,
instead of a 'user-error'. The significance of the difference is that if
the user has enabled 'toggle-debug-on-error', the typo generates an
annoying backtrace buffer that then needs to be killed, followed by a
window navigation to the gpg buffer in use.
S
--
hkp://keys.gnupg.net
CA45 09B5 5351 7C11 A9D1  7286 0036 9E45 1595 8BC0

Message #8 received at 43704 <at> debbugs.gnu.org (full text, mbox):

From: Andreas Schwab <schwab <at> linux-m68k.org>
To: Boruch Baum <boruch_baum <at> gmx.com>
Cc: 43704 <at> debbugs.gnu.org
Subject: Re: bug#43704: 26.1: gpg error on passphrase typo
Date: Tue, 29 Sep 2020 15:41:44 +0200

You can type q in the backtrace buffer to return to the previous window.

Andreas.

-- 
Andreas Schwab, schwab <at> linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."

Message #11 received at 43704 <at> debbugs.gnu.org (full text, mbox):

From: Boruch Baum <boruch_baum <at> gmx.com>
To: Andreas Schwab <schwab <at> linux-m68k.org>
Cc: 43704 <at> debbugs.gnu.org
Subject: Re: bug#43704: 26.1: gpg error on passphrase typo
Date: Tue, 29 Sep 2020 09:55:05 -0400

On 2020-09-29 15:41, Andreas Schwab wrote:
> You can type q in the backtrace buffer to return to the previous window.

Yup, I know, but that's not a fix, it's a way to cope with a bug.

--
hkp://keys.gnupg.net
CA45 09B5 5351 7C11 A9D1  7286 0036 9E45 1595 8BC0

Message #14 received at 43704 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Boruch Baum <boruch_baum <at> gmx.com>
Cc: 43704 <at> debbugs.gnu.org
Subject: Re: bug#43704: 26.1: gpg error on passphrase typo
Date: Tue, 29 Sep 2020 16:37:49 +0200

Boruch Baum <boruch_baum <at> gmx.com> writes:

> When making a mistake typing a gpg passphrase, an 'error' is generated,
> instead of a 'user-error'. The significance of the difference is that if
> the user has enabled 'toggle-debug-on-error', the typo generates an
> annoying backtrace buffer that then needs to be killed, followed by a
> window navigation to the gpg buffer in use.

Is this the backtrace you get?

Debugger entered--Lisp error: (file-missing "Opening input file" "Decryption failed" "")
  signal(file-missing ("Opening input file" "Decryption failed" ""))
  epa-file--find-file-not-found-function()
  run-hook-with-args-until-success(epa-file--find-file-not-found-function)
  find-file-noselect-1(#<killed buffer> "/tmp/foo.gpg" nil nil "/tmp/foo.gpg" (24379592 66306))
  find-file-noselect("/tmp/foo.gpg" nil nil t)
  find-file("/tmp/foo.gpg" t)
  funcall-interactively(find-file "/tmp/foo.gpg" t)
  call-interactively(find-file nil nil)
  command-execute(find-file)

I'm not sure whether there's any way for epa to know at this point
whether the failure was due to a wrong password or something else, so
I'm not sure a user-error would be appropriate.  Anybody know?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Message #17 received at 43704 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Boruch Baum <boruch_baum <at> gmx.com>
Cc: 43704 <at> debbugs.gnu.org
Subject: Re: bug#43704: 26.1: gpg error on passphrase typo
Date: Tue, 29 Sep 2020 16:41:31 +0200

Lars Ingebrigtsen <larsi <at> gnus.org> writes:

> I'm not sure whether there's any way for epa to know at this point
> whether the failure was due to a wrong password or something else, so
> I'm not sure a user-error would be appropriate.  Anybody know?

Duh.  The *error* window is right there:

----

Error while decrypting with "/usr/bin/gpg2":

gpg: AES256 encrypted data
gpg: encrypted with 1 passphrase
gpg: decryption failed: Bad session key

----

So I guess "Bad session key" is the clue here...


-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Message #20 received at 43704 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Boruch Baum <boruch_baum <at> gmx.com>
Cc: 43704 <at> debbugs.gnu.org
Subject: Re: bug#43704: 26.1: gpg error on passphrase typo
Date: Wed, 30 Sep 2020 03:48:04 +0200

Lars Ingebrigtsen <larsi <at> gnus.org> writes:

> So I guess "Bad session key" is the clue here...

This is now fixed in Emacs 28.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Message #27 received at 43704 <at> debbugs.gnu.org (full text, mbox):

From: Boruch Baum <boruch_baum <at> gmx.com>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: 43704 <at> debbugs.gnu.org
Subject: Re: bug#43704: 26.1: gpg error on passphrase typo
Date: Wed, 30 Sep 2020 02:33:09 -0400

On 2020-09-30 03:48, Lars Ingebrigtsen wrote:
> Lars Ingebrigtsen <larsi <at> gnus.org> writes:
>
> > So I guess "Bad session key" is the clue here...
>
> This is now fixed in Emacs 28.

Thank you, Lars. Meanwhile, debian is still using emacs 26, but for
development I'm now set up to receive emacs 28 snapshots with a 7-14 day
delay, I think.

--
hkp://keys.gnupg.net
CA45 09B5 5351 7C11 A9D1  7286 0036 9E45 1595 8BC0

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.