bug#43704: 26.1: gpg error on passphrase typo

bug#43704: 26.1: gpg error on passphrase typo

[Boruch Baum]

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

bug#43704: 26.1: gpg error on passphrase typo

[Andreas Schwab]

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

Andreas.

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

bug#43704: 26.1: gpg error on passphrase typo

[Boruch Baum]

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

bug#43704: 26.1: gpg error on passphrase typo

[Lars Ingebrigtsen]

Boruch Baum <boruch_baum@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

bug#43704: 26.1: gpg error on passphrase typo

[Lars Ingebrigtsen]

Lars Ingebrigtsen <larsi@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

bug#43704: 26.1: gpg error on passphrase typo

[Lars Ingebrigtsen]

Lars Ingebrigtsen <larsi@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

bug#43704: 26.1: gpg error on passphrase typo

[Boruch Baum]

On 2020-09-30 03:48, Lars Ingebrigtsen wrote:
> Lars Ingebrigtsen <larsi@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