bug#40248: 27.0.90; Failure open .authinfo.gpg from Gnus

[Eli Zaretskii]

> From: Juan José García Ripoll
>  <juanjose.garcia.ripoll@csic.es>
> Date: Fri, 27 Mar 2020 00:07:28 +0100
> 
> 1. Gnus calls nnimap-open-connection-1
> 2. nnimap-open-connection-1 binds (coding-system-for-read 'binary)
> 3. nnimap-credentials is invoked, which starts a chaing of calls ending
> up in epg-config--make-gpg-configuration
> 4. This function uses call-process

Can you provide more details regarding the chain of calls mentioned in
3 above?

> 5. Because the coding system is set to 'binary, the DOS ^M characters
> are exposed and stored in the temporary buffer.

If you use add-variable-watcher to watch any changes to
coding-system-for-read, does that allow to tell where does it get set
to 'binary' in this recipe?

> a. Set a suitable value for the encoding around call-process in
> epg-config--make-gpg-configuration. Unfortunately, I do not know which
> value would work in non-Windows platforms.

I don't think this is viable, and not only for Windows, because
there isn't sufficient context at this point to decide which encoding
to use.  This must be decided at a higher level, specifically where
coding-system-for-read is set to 'binary'.

> b. Rewrite all regexps in epg-config--make-gpg-configuration to ignore
> ^M characters.

That'd be a kludge in my book: working around our own bugs, instead of
fixing them.

> -  (let (config groups type args)
> +  (let (config groups type args (coding-system-for-read nil))

Setting coding-system-for-read to nil is not a good idea.  How do you
know what that means, and how it will affect the called process?

Thanks.