Hello,

I'm testing mutt and neomutt behaviour and I don't know if what I see is
the correct behavior of the application. I am able to sent and receive
signed and encrypted mails. I set up a proper line in configuration file
for it, like for eg.:

XIV. Configuring Mutt For Use With GnuPG https://codesorcery.net/old/mutt/mutt-gnupg-howto

Because I'm working in only text environment and I had a problem with
it, I modified the config file by removing "--batch" and
"--passphrase-fd 0" so mutt is asking for passphrase every time I need
it.

I am aware that I can add "fcc_clear" to save unencrypted sent mails,
but I'm not using it.

I am aware that I can also add "--encrypt-to" to encrypt mails with two
public keys (recipientd an my one). But I am not doing this for now.

So I sent a mail, with PGP option "both" which I understood as "to sign"
and "to encrypt", then I switched to sent mails. I can see my e-mail,
and I can't see its encrypted content.

But mutt and neomutt are showing a strange request for passphrase. And
what is more the "focus" isn't in that line, so I can't put there any
text. After I'm pressing ctrl+c application is showing expected message
"[-- Error: decryption failed --]".

Maybe I miss configured something, so please describe me what is the
correct behaviour in that situation?

Best regards,

--
.-=-. Szczezuja; on the small-net:
( S\ \ gemini://szczezuja.space/ - gemlog & tinylog
`--' / gopher://sdf.org:70/0/users/szczezuja/ - phlog

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Tue, 23 Aug 2022 19:27:45 -0000 (UTC), Szczezuja.space wrote:

[ snip ]

Because I'm working in only text environment and I had a problem with
it, I modified the config file by removing "--batch" and
"--passphrase-fd 0" so mutt is asking for passphrase every time I need
it.

[ snip ]

But mutt and neomutt are showing a strange request for passphrase. And
what is more the "focus" isn't in that line, so I can't put there any
text. After I'm pressing ctrl+c application is showing expected message
"[-- Error: decryption failed --]".

I've used the Debian example gpg.rc (installed by default in Debian distributions in /usr/share/doc/mutt/examples/gpg.rc) for over a decade
and it has always worked for me (I run mutt in either GNU screen or tmux exclusively, so also a text-only environment).

I note that the command that would be used to decrypt a message is as
follows (line wrapping mine):

---
# decrypt a pgp/mime attachment
set pgp_decrypt_command="gpg --status-fd=2 %?p?--passphrase-fd 0
--pinentry-mode=loopback? --no-verbose --quiet --batch
--output - %f"
---

It includes both --batch and --passphrase-fd 0, so I suspect removing
those arguments were an error on your part and as a result gpg is unable
to read your input (the passphrase). The gpg(1) manpage notes that since version 2.0 --batch is required for --passphrase-fd and further that --pinentry-mode loopback is required in version 2.1.

Based on the Mutt manual[1]'s note that pinentry does not function on
tty systems I believe what you are missing is the "--pinentry-mode
loopback" option.

There is also some discussion that seems similar to your problem in the
Debian bug[2] filed against the mutt package.

[1] http://mutt.org/doc/manual/#enc-pgp
[2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=828751

--
"The avalanche has started, it is too late for the pebbles to vote."
--Kosh

--- SoupGate-Win32 v

On 2022-08-23, Matthew Ernisse <[email protected]> wrote:

On Tue, 23 Aug 2022 19:27:45 -0000 (UTC), Szczezuja.space wrote:

I've used the Debian example gpg.rc (installed by default in Debian distributions in /usr/share/doc/mutt/examples/gpg.rc) for over a decade
and it has always worked for me (I run mutt in either GNU screen or tmux exclusively, so also a text-only environment).

Thanks for your reply. I'm investigating my configuration and your
sources. I haven't set the proper configuration yet.

But going back to my question, could you describe the proper behaviour
of the mutt application in such situation - decrypting a message where a default public key isn't fit (as I've written, when I sent encrypted
mail to someone else).

Thanks,

--
.-=-. Szczezuja; on the small-net:
( S\ \ gemini://szczezuja.space/ - gemlog & tinylog
`--' / gopher://sdf.org:70/0/users/szczezuja/ - phlog

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Sun, 28 Aug 2022 18:52:53 -0000 (UTC), Szczezuja.space wrote:

But going back to my question, could you describe the proper behaviour
of the mutt application in such situation - decrypting a message where a default public key isn't fit (as I've written, when I sent encrypted
mail to someone else).

If I am understanding your configuration as you described in <[email protected]> the resultant behavior
appears correct to me.

You have signed a message with your private key so naturally you can verify
it with your public key; however, as you have encrypted that message with
only your recipient's public key you will be unable to decrypt it.

You may want to brush up on how private key cryptography works and which operations use which key in the pair to better understand what is happening here.

--
"The avalanche has started, it is too late for the pebbles to vote."
--Kosh

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2022-08-29, Matthew Ernisse <[email protected]> wrote:

On Sun, 28 Aug 2022 18:52:53 -0000 (UTC), Szczezuja.space wrote:

But going back to my question, could you describe the proper behaviour
of the mutt application in such situation - decrypting a message where a
default public key isn't fit (as I've written, when I sent encrypted
mail to someone else).

If I am understanding your configuration as you described in
<[email protected]> the resultant behavior
appears correct to me.

You have signed a message with your private key so naturally you can verify it with your public key; however, as you have encrypted that message with only your recipient's public key you will be unable to decrypt it.

You may want to brush up on how private key cryptography works and which operations use which key in the pair to better understand what is happening here.

Unfortunately I'm still facing the problem with decryption. I've been
browsing source code: https://neomutt.org/code/pgp_8c.html#ab1d25d86d6ee4e2f88ef7102fa9477e6
so I'm knowing that the proper behaviour is "decryption failed" message.

Mutt is showing the message "No such file or directory", but after I've
run it in debug mode I've seen that it isn't the clue of my problem.

My debug file is something like bellow:

[...]
[2022-09-20 18:38:11]<1> pgp_decrypt_part() created temp file '/tmp/neomutt-f4vBDi'
[...]
[2022-09-20 18:38:11]<2> mutt_pgp_command() gpg --status-fd=2 --passphrase-fd 0
--no-verbose --quiet --batch /tmp/neomutt-sdf-60633-14988-5733883537168725555 [...]
[2022-09-20 18:38:11]<2> pgp_check_decryption_okay() DECRYPTION_OKAY encountered
[...]
[2022-09-20 18:38:11]<2> pgp_copy_checksig() "[GNUPG:] GOODSIG FC8D23AA13E5C43F
Szczezuja <[email protected]>" matches regex
[...]
[2022-09-20 18:38:11]<E> pgp_decrypt_part() Decryption failed
[...]

It seems that pgp_decrypt_part() has a proper output of pgp_check_decryption_okay() and pgp_copy_checksig() but it's returning "Decryption failed" what is unclear for me.

Probably the source of the problem is in the version: NeoMutt 20211015
and GPGME: 1.15.1 and gpg (GnuPG) 1.4.23. I'm not able to use GPGPME, so
I am trying to set a correct gpg.rc and so on.

There aren't good words about it: https://github.com/neomutt/neomutt/issues/1866

"Unless you're a crypto wizard, we recommend a single setting instead: set crypt_use_gpgme = yes"

So I'm a crypto wizard. :-)

--
.-=-. Szczezuja; on the small-net:
( S\ \ gemini://szczezuja.space/ - gemlog & tinylog
`--' / gopher://sdf.org:70/0/users/szczezuja/ - phlog

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2022-09-20, Szczezuja.space <[email protected]> wrote:

On 2022-08-29, Matthew Ernisse <[email protected]> wrote:

On Sun, 28 Aug 2022 18:52:53 -0000 (UTC), Szczezuja.space wrote:

Unfortunately I'm still facing the problem with decryption.

[...]

There aren't good words about it: https://github.com/neomutt/neomutt/issues/1866

"Unless you're a crypto wizard, we recommend a single setting instead: set crypt_use_gpgme = yes"

So I'm a crypto wizard. :-)

I'd like to write a few words because I finally solved my problems. It
seems that I mixed everything and that made me not be able to configure
it.

So as I understand for now:

If mutt is set to use GPGME it is using gpg2 commands, not gpg
commands what I had thought.

I had been testing everything through gpg commands, and finally I
discovered that gpg import isn't the same as gpg2 import. My private key
was inaccessible for gpg2.

In opposite way when I was configuring gpg-agent I wasn't aware that it
is never used by gpg command (only by gpg2 command) because gpg-agent
is part of gpg2.

So finally I was getting an error while accessing private key through
gpg2, or getting passpharse error through gpg-agent. There was two
different errors.

Because I was mixing commands in gpg.rc file sometimes I had signing
working, while it was going through gpg command. It was the weirdest
thing that decryption was never working and produced random messages in
mutt "can't copy message" or general "decryption failed" messages.

And even when I was trying GPGME and gpg-agent I had a third issue.
Because there wasn't set GPG_TTY env variable, and there was problem
with pinentry for gpg-agent.

Everything was weird, but a proper config:

gpg2 --list-secret-key showing my key,
crypt_use_gpgme is yes,
pgp_use_gpg_agent is yes,
GPG-TTY is set

and everything is working fine.

So it's true that it should all work out of the box. The information that
GPGME has problems with mutt is probably outdated. The same, example gpg.rc
and examples of pgp_decrypt_command mappings and so on.

Cheers!

--
.-=-. Szczezuja; on the small-net:
( S\ \ gemini://szczezuja.space/ - gemlog & tinylog
`--' / gopher://sdf.org:70/0/users/szczezuja/ - phlog

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)