Discussion:
mutt-1.5.23_9 && gnupg-2.1.6
(too old to reply)
Matthias Apitz
2015-12-23 07:04:26 UTC
Permalink
Hello,

I'm using on my FreeBSD 11-CURRENT netbook gnupg-2.1.6 to encrypt my
files and will now use this as well together with mutt to sign mails or
encrypt them with public keys of the recipients;

I search around to get a tutorial for the correct settings in .muttrc,
but the things seem to be outdated; for example the installed
/usr/local/share/examples/mutt/gpg.rc refers to some wrapper
http://70t.de/download/gpg-2comp.tar.gz which is based on GnuPG v1.x
and the tutorial http://codesorcery.net/old/mutt/mutt-gnupg-howto is
from 2001 :-(

Any kind sould here who could point me to an actual one for GnuPG v2?
Thanks

matthias
--
Matthias Apitz, ✉ ***@unixarea.de, 🌐 http://www.unixarea.de/ ☎ +49-176-38902045
Matthias Apitz
2015-12-24 07:58:55 UTC
Permalink
Post by Matthias Apitz
Hello,
I'm using on my FreeBSD 11-CURRENT netbook gnupg-2.1.6 to encrypt my
files and will now use this as well together with mutt to sign mails or
encrypt them with public keys of the recipients;
I search around to get a tutorial for the correct settings in .muttrc,
but the things seem to be outdated; for example the installed
/usr/local/share/examples/mutt/gpg.rc refers to some wrapper
http://70t.de/download/gpg-2comp.tar.gz which is based on GnuPG v1.x
and the tutorial http://codesorcery.net/old/mutt/mutt-gnupg-howto is
from 2001 :-(
Hello,

I got off-list some hints (thanks for them); after setting a bunch of
pgp_* values in ~/.muttrc I run into some GnuPG 2.1.x related problems;
it turned out, after bringing them up in the GnuPG mailing-list, that
one pnly need one(!) single value in .muttrc; and this works very
nicely; I'm attaching the hint from this mailing list;

matthias
To: Matthias Apitz <***@unixarea.de>
Cc: gnupg-***@gnupg.org
Subject: Re: signing mails with MUA mutt fails
Post by Matthias Apitz
To sign mails one configure in the MUA the command in the following
You should put

set crypt_use_gpgme

into your ~/.muttrc to use the modern (ie. from ~2003) version of Mutt's
crypto layer. it works much better that the bunch of configured commands.
Post by Matthias Apitz
gpg2 --batch --output - --passphrase-fd 0 --armor --sign --detach-sign --textmode -u %a %f
--passphrase-fd 0

does not work with gpg2 (since 2.1) because the gpg-agent is responsible
for the private keys and the passphrase to protect them. If you are
using an xterm the GUI Pinentry pops up from the background (controlled
by the existence of the DISPLAY envvar). If you are using a plain tty,
either the curses pinentry or the dump tty only pinentry can be used.
The curses pinentry is used part of the GUI pinentry and used if DISPLAY
is not set. Take care to set the GPG_TTY envvar (man gpg-agent).

If you really need it with 2.1 you may also use the loopback mode which
allows to gpg2 for ask for a passphrase in a similar but not indentical
way gpg1 and pgp did. Put

allow-loopback-pinentry

into ~/.gnupg/gpg-agent.conf and restart the agent. Add

--pinentry-mode=loopback

to the gpg command line.
Post by Matthias Apitz
running with --debug gives some kind of error in the communication with
$ killall gpg-agent
gpg: DBG: chan_7 -> AGENT_ID
gpg: DBG: chan_7 <- ERR 67109139 Unknown IPC command <GPG Agent>
That error is expected: it is a test for the former GNOME gpg-agent
replacement.
Post by Matthias Apitz
gpg: DBG: chan_7 <- ERR 83886340 Invalid IPC response <Pinentry>
gpg: signing failed: Invalid IPC response
Something is wrong with your pinentry. To debug this you add

--8<---------------cut here---------------start------------->8---
log-file /foo/bar/gpg-agent.log
verbose
debug-pinentry
debug ipc
--8<---------------cut here---------------end--------------->8---

into gpg-agent.conf ("debug ipc" Is the same as "debug 1024")


Salam-Shalom,

Werner
--
Matthias Apitz, ✉ ***@unixarea.de, 🌐 http://www.unixarea.de/ ☎ +49-176-38902045
Kevin J. McCarthy
2015-12-24 14:57:59 UTC
Permalink
Post by Matthias Apitz
I got off-list some hints (thanks for them); after setting a bunch of
pgp_* values in ~/.muttrc I run into some GnuPG 2.1.x related problems;
it turned out, after bringing them up in the GnuPG mailing-list, that
one pnly need one(!) single value in .muttrc; and this works very
nicely; I'm attaching the hint from this mailing list;
Alternatively, you could try
set pgp_use_gpg_agent

With that set, the classic interface should work fine with gpg 2.1.
--
Kevin J. McCarthy
GPG Fingerprint: 8975 A9B3 3AA3 7910 385C 5308 ADEF 7684 8031 6BDA
http://www.8t8.us/configs/gpg-key-transition-statement.txt
Matthias Apitz
2015-12-25 07:11:34 UTC
Permalink
Post by Matthias Apitz
Hello,
...
it turned out, after bringing them up in the GnuPG mailing-list, that
one only needs one(!) single value in .muttrc; and this works very
nicely; I'm attaching the hint from this mailing list;
matthias
Subject: Re: signing mails with MUA mutt fails
Post by Matthias Apitz
To sign mails one configure in the MUA the command in the following
You should put
set crypt_use_gpgme
into your ~/.muttrc to use the modern (ie. from ~2003) version of Mutt's
crypto layer. it works much better that the bunch of configured commands.
...
One small problem remains:

When I need to decrypt a message which was ciphered with my pub key, the
following process chain is asking for the passphrase to use my secret
key:

$ ps ax | egrep 'mutt|gpg|pin'
1909 - Ss 0:00,01 gpg-agent --homedir /home/guru/.gnupg --use-standard-socket --daemon
1910 - S 0:00,04 pinentry --display :0 (pinentry-tty)
1890 1 S+ 0:00,22 mutt
1906 1 S+ 0:00,06 gpg2 --enable-special-filenames --batch --no-sk-comments --lc-messages es_ES
1912 2 S+ 0:00,00 egrep mutt|gpg|pin

In the mutt' terminal (a uRxvt) the screen is a bit mangled:


...
Invoking PGP...Please enter the passphrase to unlock the OpenPGP secret key:
"Matthias Apitz (GnuPGv2) <***@unixarea.de>"
2048-bit ELG key, ID 6C7E963A56E2D675,
created 2015-12-22 (main key ID FFEE762B922A6CBB).

Passphrase:

i.e. the \n at the end of each line is not interpreted anymore as \n+\r;
also the ENTER key sends only a \r to the STDIN of pinentry which is not
understood either as the end of the keyed-in passphrase; it took me some
time to figure out that I have to use Ctrl-j to end the passphrase; with
this all is fine, apart of the mangeled message above;

Any ideas, apart of using the X11 version of pinentry?

Btw: When I sign a message and it needs the passphrase, all is fine like
this:

Please enter the passphrase to unlock the OpenPGP secret key:
"Matthias Apitz (GnuPGv2) <***@unixarea.de>"
2048-bit DSA key, ID FFEE762B922A6CBB,
created 2015-12-22.

Passphrase:


matthias
--
Matthias Apitz, ✉ ***@unixarea.de, 🌐 http://www.unixarea.de/ ☎ +49-176-38902045
Ian Zimmerman
2015-12-26 02:57:05 UTC
Permalink
Post by Matthias Apitz
...
i.e. the \n at the end of each line is not interpreted anymore as \n+\r;
also the ENTER key sends only a \r to the STDIN of pinentry which is not
understood either as the end of the keyed-in passphrase; it took me some
time to figure out that I have to use Ctrl-j to end the passphrase; with
this all is fine, apart of the mangeled message above;
Looks like raw vs. cooked mode issue. Should be fixable with stty.
--
Please *no* private copies of mailing list or newsgroup messages.
Rule 420: All persons more than eight miles high to leave the court.
Matthias Apitz
2015-12-26 05:32:03 UTC
Permalink
Post by Ian Zimmerman
Post by Matthias Apitz
...
i.e. the \n at the end of each line is not interpreted anymore as \n+\r;
also the ENTER key sends only a \r to the STDIN of pinentry which is not
understood either as the end of the keyed-in passphrase; it took me some
time to figure out that I have to use Ctrl-j to end the passphrase; with
this all is fine, apart of the mangeled message above;
Looks like raw vs. cooked mode issue. Should be fixable with stty.
Ofc, but I think, this must be done inside mutt itsef, which hands over
the tty in this state;

matthias
--
Matthias Apitz, ✉ ***@unixarea.de, http://www.unixarea.de/ ☎ +49-176-38902045
Ian Zimmerman
2015-12-26 06:22:01 UTC
Permalink
Post by Matthias Apitz
Post by Ian Zimmerman
Looks like raw vs. cooked mode issue. Should be fixable with stty.
Ofc, but I think, this must be done inside mutt itsef, which hands over
the tty in this state
Ah, right. Do you see the "Invoking GPG" message also in the second
(good) case? If not, maybe the code issuing it is responsible.

I myself use the "obsolete" pre-gpgme code, so I can't help more with
this, sorry.
--
Please *no* private copies of mailing list or newsgroup messages.
Rule 420: All persons more than eight miles high to leave the court.
Matthias Apitz
2015-12-26 06:39:19 UTC
Permalink
Post by Ian Zimmerman
Post by Matthias Apitz
Post by Ian Zimmerman
Looks like raw vs. cooked mode issue. Should be fixable with stty.
Ofc, but I think, this must be done inside mutt itsef, which hands over
the tty in this state
Ah, right. Do you see the "Invoking GPG" message also in the second
(good) case? If not, maybe the code issuing it is responsible.
I myself use the "obsolete" pre-gpgme code, so I can't help more with
this, sorry.
I fixed it with:

$ cat ~/.gnupg/gpg-agent.conf
pinentry-program /home/guru/pinentry.sh

$ cat /home/guru/pinentry.sh
#!/bin/sh
stty cooked < $GPG_TTY
/usr/local/bin/pinentry $*
stty raw < $GPG_TTY

Thanks

matthias
--
Matthias Apitz, ✉ ***@unixarea.de, 🌐 http://www.unixarea.de/ ☎ +49-176-38902045
Kevin J. McCarthy
2015-12-26 16:34:58 UTC
Permalink
Post by Matthias Apitz
Post by Ian Zimmerman
Post by Matthias Apitz
...
i.e. the \n at the end of each line is not interpreted anymore as \n+\r;
also the ENTER key sends only a \r to the STDIN of pinentry which is not
understood either as the end of the keyed-in passphrase; it took me some
time to figure out that I have to use Ctrl-j to end the passphrase; with
this all is fine, apart of the mangeled message above;
Looks like raw vs. cooked mode issue. Should be fixable with stty.
Ofc, but I think, this must be done inside mutt itsef, which hands over
the tty in this state;
Mutt uses cbreak mode, but doesn't toggle raw/cooked mode anywhere as
far as I can tell. In this case, the "Invoking PGP..." message is
output before starting to display an encrypted message. It's
generated by a mvaddstr() and refresh().

For gpgme, mutt is just making gpgme function calls,
e.g. gpgme_op_decrypt_verify(), and then setting a flag to do a redraw
afterwards. I don't see the code doing anything much different
between decrypt/verify and signing.

Werner, can you see anything different between
gpgme_op_decrypt_verify() and gpgme_op_sign() and how they invoke
pinentry if needed?
--
Kevin J. McCarthy
GPG Fingerprint: 8975 A9B3 3AA3 7910 385C 5308 ADEF 7684 8031 6BDA
http://www.8t8.us/configs/gpg-key-transition-statement.txt
Matthias Apitz
2015-12-26 18:57:09 UTC
Permalink
Post by Kevin J. McCarthy
Mutt uses cbreak mode, but doesn't toggle raw/cooked mode anywhere as
far as I can tell. In this case, the "Invoking PGP..." message is
output before starting to display an encrypted message. It's
generated by a mvaddstr() and refresh().
For gpgme, mutt is just making gpgme function calls,
e.g. gpgme_op_decrypt_verify(), and then setting a flag to do a redraw
afterwards. I don't see the code doing anything much different
between decrypt/verify and signing.
Werner, can you see anything different between
gpgme_op_decrypt_verify() and gpgme_op_sign() and how they invoke
pinentry if needed?
The improved version of my intermidiate script is:

#!/bin/sh

save_state=$(stty -g < $GPG_TTY)
stty cooked < $GPG_TTY
/usr/local/bin/pinentry $*
stty "$save_state" < $GPG_TTY

i.e. does saving and restoring of the stty state. The problem with this
is, that the env var $GPG_TTY is stored in the proc context of the
gpg-agent daemon and if you run mutt from another xterm this does not
match the actual tty :-(

matthias
--
Matthias Apitz, ✉ ***@unixarea.de, 🌐 http://www.unixarea.de/ ☎ +49-176-38902045
Kevin J. McCarthy
2015-12-27 15:12:43 UTC
Permalink
Post by Kevin J. McCarthy
For gpgme, mutt is just making gpgme function calls,
e.g. gpgme_op_decrypt_verify(), and then setting a flag to do a redraw
afterwards. I don't see the code doing anything much different
between decrypt/verify and signing.
Ah... I was wrong. For signing/encrypting when we're about to send an
email, mutt exits curses mode (calls endwin()). But when displaying a
message, we stay in curses mode the whole time.

From your example, it looks like you are using the TTY-based pinentry
program, which probably would behave rather goofily when mutt is still
in curses mode.

Would you mind trying the curses enabled version?
--
Kevin J. McCarthy
GPG Fingerprint: 8975 A9B3 3AA3 7910 385C 5308 ADEF 7684 8031 6BDA
http://www.8t8.us/configs/gpg-key-transition-statement.txt
Matthias Apitz
2015-12-27 15:47:14 UTC
Permalink
Post by Kevin J. McCarthy
Ah... I was wrong. For signing/encrypting when we're about to send an
email, mutt exits curses mode (calls endwin()). But when displaying a
message, we stay in curses mode the whole time.
From your example, it looks like you are using the TTY-based pinentry
program, which probably would behave rather goofily when mutt is still
in curses mode.
Would you mind trying the curses enabled version?
Yes, I have it installed now; it looks rather ugly, but works fine with
mutt; thanks

matthias
--
Matthias Apitz, ✉ ***@unixarea.de, 🌐 http://www.unixarea.de/ ☎ +49-176-38902045
Kevin J. McCarthy
2015-12-28 17:58:38 UTC
Permalink
Some are annoying, but haven't been able to articulate them well enough
to file a bug.
So one issue involves redraw, but the easier one to reproduce is that
when invoking gpg-agent the first time, after entering my passphrase for
Invoking PGP...
in the status bar while viewing the message, even after the message has
been successfully decrypted.
This should be with the curses, vs. tty, interface to pinentry.
Okay thanks Will, I will take a look at this. (I'm in the middle of a
few other mutt-things, but I'll get to it as soon as I can.)

Matthias, I'll also take a look at the decrypt TTY-mode issue too.
Perhaps it's possible to wrap an endwin/refresh inside the decryption
handler or somewhere in that sequence.
--
Kevin J. McCarthy
GPG Fingerprint: 8975 A9B3 3AA3 7910 385C 5308 ADEF 7684 8031 6BDA
http://www.8t8.us/configs/gpg-key-transition-statement.txt
Kevin J. McCarthy
2016-02-10 02:52:29 UTC
Permalink
Some are annoying, but haven't been able to articulate them well enough
to file a bug.
So one issue involves redraw, but the easier one to reproduce is that
when invoking gpg-agent the first time, after entering my passphrase for
Invoking PGP...
in the status bar while viewing the message, even after the message has
been successfully decrypted.
This should be with the curses, vs. tty, interface to pinentry.
I finally was able to install a KVM instance of FreeBSD 10.2. This has
gpg 2.1.8, and I set up to use pinentry-curses.

With the latest mutt tip built there, I'm not seeing any problems after
decryption. The pinentry-curses completely clears the screen when it
shows the prompt, and then afterwards the status bar shows "PGP message
successfully decrypted."

Now, that said, my testing is limited by the fact that I'm ssh'ing into
the instance from my Debian testing computer. Perhaps there are some
terminal issues I'm not hitting this way.
--
Kevin J. McCarthy
GPG Fingerprint: 8975 A9B3 3AA3 7910 385C 5308 ADEF 7684 8031 6BDA
http://www.8t8.us/configs/gpg-key-transition-statement.txt
Kevin J. McCarthy
2016-02-11 17:13:42 UTC
Permalink
Post by Kevin J. McCarthy
With the latest mutt tip built there, I'm not seeing any problems after
decryption. The pinentry-curses completely clears the screen when it
shows the prompt, and then afterwards the status bar shows "PGP message
successfully decrypted."
Now, that said, my testing is limited by the fact that I'm ssh'ing into
the instance from my Debian testing computer. Perhaps there are some
terminal issues I'm not hitting this way.
I've got 1.5.23 from ports, and using Apple Terminal, though don't think
that's the issue. $TERM is xterm-256color (though xterm behaves the same
way).
System: FreeBSD 9.3-RELEASE-p33 (amd64)
ncurses: ncurses 5.7.20081102 (compiled with 5.7)
set crypt_use_gpgme=yes
or are you using manual gpg commands?
Thanks for the suggestion - that was the problem: I forgot to try it
with gpgme! With gpgme, I can reproduce "Invoking PGP..." being stuck
in the message after decryption. I'll get a patch in for that. Please
let me know if there are other issues you see.
--
Kevin J. McCarthy
GPG Fingerprint: 8975 A9B3 3AA3 7910 385C 5308 ADEF 7684 8031 6BDA
http://www.8t8.us/configs/gpg-key-transition-statement.txt
Kevin J. McCarthy
2016-02-17 00:32:34 UTC
Permalink
(without passphrase already cached by GPG), use 'limit' to find an
encrypted, *traditional* (not pgp-MIME) message in a folder. In some
cases, not completely reproducible, I then only see the 'S' in the index
lines that show up (when $pager_index_lines is set), and I see artifacts
of the pinentry page, sometimes sticking around for a while. The
screenshot here should show the behavior.
Additionally, after this problem comes up, the up arrow in the 'limit'
pattern doesn't work (I get, e.g., [A for up-arrow), though I can still
type in there Ok.
Just to help me track this: do you have $pgp_auto_decode set, or are you
typing Esc-P inside the pager? It sounds like we need to trigger a hard
redraw (which also turns keypad back on) on whatever path this is
following.

Also, does this only happen when you limit?
One other question -- it looks like $pgp_create_traditional doesn't work
with the $crypt_use_gpgme backend. The docs do kind of imply that, but
maybe it should also generate a startup warning if you have
$crypt_use_gpgme and $pgp_create_traditional both set?,
Okay I'll look into this too.
--
Kevin J. McCarthy
GPG Fingerprint: 8975 A9B3 3AA3 7910 385C 5308 ADEF 7684 8031 6BDA
http://www.8t8.us/configs/gpg-key-transition-statement.txt
Kevin J. McCarthy
2016-03-02 23:17:25 UTC
Permalink
Post by Kevin J. McCarthy
(without passphrase already cached by GPG), use 'limit' to find an
encrypted, *traditional* (not pgp-MIME) message in a folder. In some
cases, not completely reproducible, I then only see the 'S' in the index
lines that show up (when $pager_index_lines is set), and I see artifacts
of the pinentry page, sometimes sticking around for a while. The
screenshot here should show the behavior.
Additionally, after this problem comes up, the up arrow in the 'limit'
pattern doesn't work (I get, e.g., [A for up-arrow), though I can still
type in there Ok.
Just to help me track this: do you have $pgp_auto_decode set, or are you
typing Esc-P inside the pager? It sounds like we need to trigger a hard
redraw (which also turns keypad back on) on whatever path this is
following.
I don't have $pgp_auto_decode set, but because the messages were created
via mutt (with older GPG and $pgp_create_traditional), there's an
x-header, so I don't have to explicitly hit esc-p.
Post by Kevin J. McCarthy
Also, does this only happen when you limit?
It seemed to be easier to reproduce that way, I'll try it the other way
with some non-pgp-MIME messages.
After tracing through, it does turn out the GPGME code was missing a
hard redraw call for application/pgp handling. I've added this and
pushed it up. It should take care of the artifact and keyboard issues.
Please let me know if it does not.

I also added a note to the $pgp_autoinline and $crypt_use_gpgme options
about gpgme not supporting creating inline pgp.
--
Kevin J. McCarthy
GPG Fingerprint: 8975 A9B3 3AA3 7910 385C 5308 ADEF 7684 8031 6BDA
http://www.8t8.us/configs/gpg-key-transition-statement.txt
Loading...