bug#45916: 28.0.50; Inconsistent EasyPG behaviour when encrypting .gpg files

bug#45916: 28.0.50; Inconsistent EasyPG behaviour when encrypting .gpg files

[Pankaj Jangid]

It used to work until 1-2 months back. Sorry for reporting lated.

1. emacs -Q

2. eval ‘(defvar epg-pinentry-mode 'loopback)’

3. C-c C-f ~/x.gpg RET

4. Write some text

5. C-x C-s ; this prompts for selecting key and saves using that.

6. C-x k ;

7. C-c C-f ~/x.gpg RET ; open again

8. make some changes

9. C-x C-s ; asks for passphrase for symmetric key encryption

This, I think is a bug.

Behaviour in step 5 and 9 should be same. _Or_ if the file was already
saved encrypted with a public-key then it should use the same key again.

I am on macOS at present, but I noticed similar behaviour on Debian last
week.


In GNU Emacs 28.0.50 (build 1, x86_64-apple-darwin20.2.0, NS appkit-2022.20 Version 11.1 (Build 20C69))
 of 2021-01-16 built on mb2.local
Repository revision: f45be48ddbde00610e1e08fca6590dcf24a4e1b5
Repository branch: master
Windowing system distributor 'Apple', version 10.3.2022
System Description:  macOS 11.1

Configured features:
ACL DBUS GIF GLIB GMP GNUTLS JPEG JSON LCMS2 LIBXML2 MODULES NOTIFY
KQUEUE NS PDUMPER PNG RSVG THREADS TIFF TOOLKIT_SCROLL_BARS XIM ZLIB

Important settings:
  value of $LC_CTYPE: UTF-8
  value of $LANG: en_US
  locale-coding-system: utf-8-unix

Major mode: Lisp Interaction

Minor modes in effect:
  tooltip-mode: t
  global-eldoc-mode: t
  eldoc-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  line-number-mode: t
  transient-mark-mode: t

Load-path shadows:
None found.

Features:
(shadow sort mail-extr emacsbug message rmc puny dired dired-loaddefs
rfc822 mml easymenu mml-sec gnus-util rmail rmail-loaddefs auth-source
cl-seq eieio eieio-core cl-macs eieio-loaddefs password-cache json map
text-property-search mm-decode mm-bodies mm-encode mail-parse rfc2231
mailabbrev gmm-utils mailheader sendmail rfc2047 rfc2045 ietf-drums
mm-util mail-prsvr mail-utils seq byte-opt gv bytecomp byte-compile
cconv epa-file epa derived epg epg-config time-date subr-x cl-loaddefs
cl-lib iso-transl tooltip eldoc electric uniquify ediff-hook vc-hooks
lisp-float-type mwheel term/ns-win ns-win ucs-normalize mule-util
term/common-win tool-bar dnd fontset image regexp-opt fringe
tabulated-list replace newcomment text-mode elisp-mode lisp-mode
prog-mode register page tab-bar menu-bar rfn-eshadow isearch timer
select scroll-bar mouse jit-lock font-lock syntax facemenu font-core
term/tty-colors frame minibuffer cl-generic cham georgian utf-8-lang
misc-lang vietnamese tibetan thai tai-viet lao korean japanese eucjp-ms
cp51932 hebrew greek romanian slovak czech european ethiopic indian
cyrillic chinese composite charscript charprop case-table epa-hook
jka-cmpr-hook help simple abbrev obarray cl-preloaded nadvice button
loaddefs faces cus-face macroexp files window text-properties overlay
sha1 md5 base64 format env code-pages mule custom widget
hashtable-print-readable backquote threads dbusbind kqueue cocoa ns
lcms2 multi-tty make-network-process emacs)

Memory information:
((conses 16 52551 9056)
 (symbols 48 6820 1)
 (strings 32 18053 2283)
 (string-bytes 1 596654)
 (vectors 16 12513)
 (vector-slots 8 170100 10014)
 (floats 8 21 33)
 (intervals 56 214 0)
 (buffers 984 11))

bug#45916: 28.0.50; Inconsistent EasyPG behaviour when encrypting .gpg files

[Pankaj Jangid]

> 1. emacs -Q
> 2. eval ‘(defvar epg-pinentry-mode 'loopback)’
> 3. C-c C-f ~/x.gpg RET
> 4. Write some text
> 5. C-x C-s ; this prompts for selecting key and saves using that.
> 6. C-x k ;
> 7. C-c C-f ~/x.gpg RET ; open again
> 8. make some changes
> 9. C-x C-s ; asks for passphrase for symmetric key encryption

> Behaviour in step 5 and 9 should be same. _Or_ if the file was already
> saved encrypted with a public-key then it should use the same key again.

More info (it is fixed after invoking ‘M-x epa-file-select-keys’)

Now I opened ~/x.gpg again and invoke ‘M-x epa-file-select-keys’ and
selected the desired public key and saved (C-x C-s). Now it saved the
file using the public key.

I see that, when I open a .gpg file it sets a buffer-local variable
‘epa-file-encrypt-to’. Which makes it automatically use the public key
because the value of ‘epa-file-select-keys’ is nil (default).

And after I invoked ‘M-x epa-file-select-keys’, it is consistently
behaving as described in the manuals i.e. Step (9) is not asking for
symmetric key encryption passphrase any more.

Probably the ‘epa-file-encrypt-to’ was not being set earlier after
opening a .gpg file.

My question is - does invoking ‘M-x epa-file-select-keys’ save the
information somewhere on the filesystem? Only after invoking this the
behaviour got fixed.

bug#45916: 28.0.50; Inconsistent EasyPG behaviour when encrypting .gpg files

[Lars Ingebrigtsen]

Pankaj Jangid <pankaj@codeisgreat.org> writes:

>> 1. emacs -Q
>> 2. eval ‘(defvar epg-pinentry-mode 'loopback)’
>> 3. C-c C-f ~/x.gpg RET
>> 4. Write some text
>> 5. C-x C-s ; this prompts for selecting key and saves using that.
>> 6. C-x k ;
>> 7. C-c C-f ~/x.gpg RET ; open again
>> 8. make some changes
>> 9. C-x C-s ; asks for passphrase for symmetric key encryption
>
>> Behaviour in step 5 and 9 should be same. _Or_ if the file was already
>> saved encrypted with a public-key then it should use the same key again.

(I'm going through old bug reports that unfortunately weren't resolved
at the time.)

I was unable to reproduce the bug in Emacs 29.

> My question is - does invoking ‘M-x epa-file-select-keys’ save the
> information somewhere on the filesystem? Only after invoking this the
> behaviour got fixed.

Not that I can see...

Are you still seeing any issues in this area in recent Emacs versions?
There's been quite a few bug fixes in this area over the last year, if I
remember correctly.

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