I have been using mail/mutt & security/gnupg (latter switched to security/gnupg20 back when gnupg20 port was created because of a similar-looking issue to what's described in the first part of the below narrative) for several years -- without enabling "gpgme" (in case that turns out to be relevant).
As a result, I have a collection of messages that were sent to me that
contain information that was deemed suitable for encryption; I still
have occasion to refer to the contents of some of these messages, and
prefer to leave them stored in encrypted form when I am not actively
reading them.
This morning, during the daily update of installed ports on my
laptop, I saw:
===>>> The security/gnupg20 port moved to security/gnupg
===>>> Reason: Has expired: Will reach EOL upstream on 2017-12-31
OK. I had vague memories that things didn't work very well last time
there was a "minor" upgrade to gnupg, so I deferred that part of the
upgrade until I could do a bit more research.
I soon found "Bug 196382 - security/gnupg breaks keyring on 2.1.1"
<https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=196382>. So I tried
the recipe listed in Comment 4, then verified that decryption still
worked (while gnupg20 was the version of gnupg that was installed).
That was successful, so I deleted security/gnupg20, then installed
security/gnupg; that done, I re-tried the decryption, which failed
("Could not decrypt PGP message"; "Could not copy message" -- these
messages from mutt).
I then re-did the recipe from Comment 4 (now that security/gnupg was
installed), then re-tried the decryption test; it (still) failed the
same way.
Trying the decryption again (under "ktrace -di") showed the following
messages being issued by gpg:
"gpg: WARNING: no command supplied. Trying to guess what you mean ..."
"gpg: encrypted with 2048-bit RSA key, ID C8A5439CFA5A0A07, created 201\
5-11-29"
" "David H. Wolfskill <da...@catwhisker.org>"
"gpg: public key decryption failed: Invalid IPC response"
"gpg: decryption failed: No secret key"
Following a hint obtained by searching on the above (particularly
the "gpg: public key decryption failed: Invalid IPC response" message),
I logged in to a machine that still has security/gnupg20 and used
gpg -e /etc/rc.conf
to encrypt a copy of that file with me as a recipient. Decrypting
worked (as expected).
I then copied the rc.conf.gpg from that machine to my laptop (which now
has security/gnupg installed) and attempted the decryption -- and it
worked.
Given that, I thought that perhaps the (re-)installation of mail/mutt
had been what got things working again; I was thus quite surprised when
(about 3.5 hrs. later) I got in to work and had need to decrypt a
message on my laptop, and it -- again -- failed as described above.
As a reality check, I then re-tried the decryption of rc.conf.gpg (from
above); that worked.
After a couple quick shakes of my head to help ensure that I wasn't
hallucinating, I tried reading an encrypted email message (on the
laptop) again... and this time, it worked.
In fact, going back to the first "mutt" invocation that failed at work,
merely requesting to read a message Just Worked -- my passphrase was not
requested (as I had entered it less than 2 hours earlier).
This leaves me wondering if all of the above means that before
attempting to decrypt an encrypted email message via mutt, one is
supposed to (first) use bare gpg to decrypt a file -- but that seems
ridiculous to thye point of hostility....
Does anyone have insights, clues, or pointers to same to share?
Thanks!
Peace,
david
--
David H. Wolfskill da...@catwhisker.org
If you want the best Fake News, go to the best source of it: Donald J. Trump.
See http://www.catwhisker.org/~david/publickey.gpg for my public key.
signature.asc
Description: PGP signature
