bug#67978: 29.1; ERC 5.5.0.29.1: Unnecessary .authinfo.gpg decryption causes connection failure to irc.libera.chat

bug#67978: 29.1; ERC 5.5.0.29.1: Unnecessary .authinfo.gpg decryption causes connection failure to irc.libera.chat

[Jake]

[-- Attachment #1: Type: text/plain, Size: 4826 bytes --]

Hello

I encountered an issue with authinfo interfering with ERC:
When I attempt to connect to the irc.libera.chat server with a random
nickname and no password, if a ~/.authinfo.gpg file is present on my
system (or any .gpg file in the auth-sources variable), ERC attempts to
decrypt this file when connecting. When I don't decrypt it, the
connection fails.

This occurs with emacs -Q.

If I set auth-sources to nil, or change the name of the .gpg file to
something else not in auth-sources, I get the expected behavior; i.e., it
connects to the server.

Steps to reproduce:
1. have an encrypted ~/.authinfo.gpg file (this will also be an element of
the variable auth-sources, which is the default)
2. emacs -Q
3. M-x erc-tls
interactively: RET on default values irc.libera.chat and 6697, then enter a
unique nickname and do not enter a password
4. be prompted to decrypt ~/.authinfo.gpg

Thanks
Jake


In GNU Emacs 29.1 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.33,
 cairo version 1.16.0) of 2023-11-26 built on pc
Repository revision: a9b28224af0f73d1fe0f422e9b318c5b91af889b
Repository branch: HEAD
Windowing system distributor 'The X.Org Foundation', version 11.0.12101004
System Description: Ubuntu 22.04.3 LTS

Configured using:
 'configure --with-native-compilation'

Configured features:
ACL CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS GPM GSETTINGS HARFBUZZ JPEG
JSON LCMS2 LIBOTF LIBSELINUX LIBSYSTEMD LIBXML2 M17N_FLT MODULES
NATIVE_COMP NOTIFY INOTIFY PDUMPER PNG RSVG SECCOMP SOUND THREADS TIFF
TOOLKIT_SCROLL_BARS X11 XDBE XIM XINPUT2 XPM GTK3 ZLIB

Important settings:
  value of $LANG: en_AU.UTF-8
  value of $XMODIFIERS: @im=ibus
  locale-coding-system: utf-8-unix

Major mode: Lisp Interaction

Minor modes in effect:
  erc-list-mode: t
  erc-menu-mode: t
  erc-autojoin-mode: t
  erc-ring-mode: t
  erc-track-mode: t
  erc-match-mode: t
  erc-button-mode: t
  erc-fill-mode: t
  erc-stamp-mode: t
  erc-netsplit-mode: t
  erc-irccontrols-mode: t
  erc-noncommands-mode: t
  erc-move-to-prompt-mode: t
  erc-readonly-mode: t
  erc-networks-mode: t
  tooltip-mode: t
  global-eldoc-mode: t
  eldoc-mode: t
  show-paren-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
  line-number-mode: t
  indent-tabs-mode: t
  transient-mark-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t

Load-path shadows:
None found.

Features:
(shadow sort mail-extr emacsbug message yank-media puny dired
dired-loaddefs rfc822 mml mml-sec gnus-util 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 epa-file epa derived epg rfc6068 epg-config erc-list erc-menu
erc-join erc-ring erc-pcomplete pcomplete comint ansi-osc ansi-color
ring erc-track erc-match erc-button browse-url url url-proxy url-privacy
url-expand url-methods url-history url-cookie generate-lisp-file
url-domsuf url-util mailcap wid-edit erc-fill erc-stamp erc-netsplit
url-parse url-vars erc-goodies erc iso8601 time-date auth-source eieio
eieio-core password-cache json map thingatpt pp format-spec cl-loaddefs
comp comp-cstr warnings icons subr-x rx cl-seq cl-macs cl-extra
help-mode cl-lib erc-backend erc-networks byte-opt gv bytecomp
byte-compile erc-common erc-compat erc-loaddefs rmc iso-transl tooltip
cconv eldoc paren electric uniquify ediff-hook vc-hooks lisp-float-type
elisp-mode mwheel term/x-win x-win term/common-win x-dnd tool-bar dnd
fontset image regexp-opt fringe tabulated-list replace newcomment
text-mode lisp-mode prog-mode register page tab-bar menu-bar rfn-eshadow
isearch easymenu timer select scroll-bar mouse jit-lock font-lock syntax
font-core term/tty-colors frame minibuffer nadvice seq simple cl-generic
indonesian philippine 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 emoji-zwj charscript charprop case-table epa-hook
jka-cmpr-hook help abbrev obarray oclosure cl-preloaded button loaddefs
theme-loaddefs faces cus-face macroexp files window text-properties
overlay sha1 md5 base64 format env code-pages mule custom widget keymap
hashtable-print-readable backquote threads dbusbind inotify lcms2
dynamic-setting system-font-setting font-render-setting cairo
move-toolbar gtk x-toolkit xinput2 x multi-tty make-network-process
native-compile emacs)

Memory information:
((conses 16 135458 9425)
 (symbols 48 11459 0)
 (strings 32 34227 2725)
 (string-bytes 1 1091358)
 (vectors 16 23335)
 (vector-slots 8 458080 9833)
 (floats 8 39 25)
 (intervals 56 1318 0)
 (buffers 976 13))

[-- Attachment #2: Type: text/html, Size: 5306 bytes --]

Re: 29.1; ERC 5.5.0.29.1: Unnecessary .authinfo.gpg decryption causes connection failure to irc.libera.chat

[J.P.]

Hi Jake,

Jake <jforst.mailman@gmail.com> writes:

> Hello
>
> I encountered an issue with authinfo interfering with ERC:
> When I attempt to connect to the irc.libera.chat server with a random
> nickname and no password, if a ~/.authinfo.gpg file is present on my
> system (or any .gpg file in the auth-sources variable), ERC attempts to
> decrypt this file when connecting. When I don't decrypt it, the
> connection fails.
>
> This occurs with emacs -Q.
>
> If I set auth-sources to nil, or change the name of the .gpg file to
> something else not in auth-sources, I get the expected behavior; i.e., it connects to the server.
>
> Steps to reproduce:
> 1. have an encrypted ~/.authinfo.gpg file (this will also be an element of
> the variable auth-sources, which is the default) 
> 2. emacs -Q
> 3. M-x erc-tls
> interactively: RET on default values irc.libera.chat and 6697, then enter a unique nickname and do not
> enter a password
> 4. be prompted to decrypt ~/.authinfo.gpg

I haven't tried very hard to reproduce this yet, but I can't seem to get
Emacs to prompt me from emacs -Q. It just decrypts the file straight
away if it has access to the key it was encrypted with and fails
otherwise. So, I was wondering if this prompt is coming from somewhere
external, such as a secrets manager or a TTY pinentry program, for
example,

  Please enter the passphrase to unlock the OpenPGP secret key:
  "Your Name <you@example.com>"
  3071 RSA key, ID DEAD..BEEF
  created 2023-12-22 17:30 (main key ID ...).
  
  Passprhase: ____________________________

  <OK> <Cancel>

(although, from your description, it seems like you're using graphical
Emacs). Also, is the "irc.libera.chat:6697" buffer completely blank
after the failure? And is there anything relevant recorded in the
"*Messages*" buffer? Perhaps something like:

  For information about GNU Emacs and the GNU system, type C-h C-a.
  Decrypting /root/.authinfo.gpg...done
  epa-file-insert-file-contents:
  Opening input file: Decryption failed, , No secret key

I'm mainly trying to avoid having to replicate your setup in a VM.

TIA,
J.P.

Re: 29.1; ERC 5.5.0.29.1: Unnecessary .authinfo.gpg decryption causes connection failure to irc.libera.chat

[Jake]

[-- Attachment #1: Type: text/plain, Size: 3440 bytes --]

Hi J.P.

Thanks for taking the time.

> It just decrypts the file straight
> away if it has access to the key it was encrypted with and fails
> otherwise.
It sounds like you've successfully reproduced it, because it's attempted to
decrypt the auth-source file.

Now I feel like I'm definitely missing something. Why does it do this? I
assume nothing in this file is required to connect to irc.libera.chat,
since the connection succeeds if the file is not present.

> So, I was wondering if this prompt is coming from somewhere
> external, such as a secrets manager or a TTY pinentry program
I've had the prompt from gnome keyring on Ubuntu (I assume that's what it
is) and gtk-pinentry on another machine. But my issue is that the prompt
occurs at all.

> Also, is the "irc.libera.chat:6697" buffer completely blank
> after the failure?
yes it is blank.

> And is there anything relevant recorded in the
> "*Messages*" buffer?
Decrypting /home/jake/.authinfo.gpg...done
epa-file-insert-file-contents: Opening input file: Decryption failed, , No
secret key

Thanks
Jake

On Sat, Dec 23, 2023 at 4:41 AM J.P. <jp@neverwas.me> wrote:

> Hi Jake,
>
> Jake <jforst.mailman@gmail.com> writes:
>
> > Hello
> >
> > I encountered an issue with authinfo interfering with ERC:
> > When I attempt to connect to the irc.libera.chat server with a random
> > nickname and no password, if a ~/.authinfo.gpg file is present on my
> > system (or any .gpg file in the auth-sources variable), ERC attempts to
> > decrypt this file when connecting. When I don't decrypt it, the
> > connection fails.
> >
> > This occurs with emacs -Q.
> >
> > If I set auth-sources to nil, or change the name of the .gpg file to
> > something else not in auth-sources, I get the expected behavior; i.e.,
> it connects to the server.
> >
> > Steps to reproduce:
> > 1. have an encrypted ~/.authinfo.gpg file (this will also be an element
> of
> > the variable auth-sources, which is the default)
> > 2. emacs -Q
> > 3. M-x erc-tls
> > interactively: RET on default values irc.libera.chat and 6697, then
> enter a unique nickname and do not
> > enter a password
> > 4. be prompted to decrypt ~/.authinfo.gpg
>
> I haven't tried very hard to reproduce this yet, but I can't seem to get
> Emacs to prompt me from emacs -Q. It just decrypts the file straight
> away if it has access to the key it was encrypted with and fails
> otherwise. So, I was wondering if this prompt is coming from somewhere
> external, such as a secrets manager or a TTY pinentry program, for
> example,
>
>   Please enter the passphrase to unlock the OpenPGP secret key:
>   "Your Name <you@example.com>"
>   3071 RSA key, ID DEAD..BEEF
>   created 2023-12-22 17:30 (main key ID ...).
>
>   Passprhase: ____________________________
>
>   <OK> <Cancel>
>
> (although, from your description, it seems like you're using graphical
> Emacs). Also, is the "irc.libera.chat:6697" buffer completely blank
> after the failure? And is there anything relevant recorded in the
> "*Messages*" buffer? Perhaps something like:
>
>   For information about GNU Emacs and the GNU system, type C-h C-a.
>   Decrypting /root/.authinfo.gpg...done
>   epa-file-insert-file-contents:
>   Opening input file: Decryption failed, , No secret key
>
> I'm mainly trying to avoid having to replicate your setup in a VM.
>
> TIA,
> J.P.
>

[-- Attachment #2: Type: text/html, Size: 4419 bytes --]

bug#67978: 29.1; ERC 5.5.0.29.1: Unnecessary .authinfo.gpg decryption causes connection failure to irc.libera.chat

[J.P.]

Hi Jake,

Jake <jforst.mailman@gmail.com> writes:

> Hi J.P.
>
> Thanks for taking the time.

You're very welcome.

>> It just decrypts the file straight away if it has access to the key
>> it was encrypted with and fails otherwise.
> It sounds like you've successfully reproduced it, because it's
> attempted to decrypt the auth-source file.

Hard to say, but hopefully it's close enough to what you're
experiencing.

> Now I feel like I'm definitely missing something. Why does it do this?
> I assume nothing in this file is required to connect to
> irc.libera.chat, since the connection succeeds if the file is not
> present.

Right, nothing in the file is needed unless you've arranged for it to
be. By default, ERC usually checks for server and other passwords when
the protocol presents an opportunity. In most cases, there's a specific
function-valued option, like `erc-auth-source-server-function', that
corresponds to a given opportunity. Setting any of these options to nil
typically inhibits `auth-source' queries for that particular context. So
you can always resort to that as a workaround.

>> So, I was wondering if this prompt is coming from somewhere external,
>> such as a secrets manager or a TTY pinentry program
> I've had the prompt from gnome keyring on Ubuntu (I assume that's what
> it is) and gtk-pinentry on another machine. But my issue is that the
> prompt occurs at all.
>
>> Also, is the "irc.libera.chat:6697" buffer completely blank
>> after the failure? 
> yes it is blank.
>
>> And is there anything relevant recorded in the
>> "*Messages*" buffer?
> Decrypting /home/jake/.authinfo.gpg...done
> epa-file-insert-file-contents: Opening input file: Decryption failed,
> , No secret key

That's helpful, thanks. I believe what's happening in your case is that
your Gnome Keyring's GPG integration needs attention, hopefully only in
the configuration department. If libsecret has been authorized to store
the key you're being prompted to provide a passphrase for, it should
show up when you query the service over DBus. But before messing with
that, make sure to tick the appropriate "remember this" box the next
time you provide your passphrase in a popup dialog. From then on, you
shouldn't be prompted, though you may have to log out and back in for it
to stick [1].

In any case, I think ERC users should be allowed to ignore errors
signaled by its default `auth-source' queries, so I've added a prompt
that asks whether to proceed anyway when one occurs. It's preceded by an
annoying warning, which you can customize away in the usual fashion, in
this case by setting the option `warning-suppress-types' or
`warning-suppress-log-types' to include the list (erc auth-source).

Feel free to try out the changes on HEAD [2] and report back. If that's
too much trouble, you can wait for ERC 5.6, which should be released in
the coming weeks.

Thanks,
J.P.

[1] https://emacs-erc.gitlab.io/bugs/archive/doc/erc.html#Troubleshooting-1
[2] https://git.savannah.gnu.org/cgit/emacs.git/commit/?id=5fb9d6c5