PGG/GPG Integration bug (somewhat nasty & urgent), potential mailcrypt concept bug

PGG/GPG Integration bug (somewhat nasty & urgent), potential mailcrypt concept bug

[Georg C. F. Greve]

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

Hi all,

described the following problem already in mail to Daiki & bugs@, for
context, this is where things break right now. For additional reason
to write this mail, please see POSSIBLE CONCEPT BUG below:


CONTEXT:

I am experiencing a rather nasty problem with the integration of Gnus
and GNUPG right now, which I hope you will be able to help me with.

As you may have seen, the Free Software Foundation Europe has started
a Fellowship campaign to promote digital freedom, which has its own
portal site at http://www.fsfe.org. Each fellow receives an OpenPGP
SmartCard personalised to his/her own name and with the option of
having the keys signed by the Free Software Foundation Europe.

Last Friday the first batch of SmartCards was shipped and I am
currently starting to move to using the SmartCard as my default
personal crypto-token.

Unfortunately, this turns using Gnus into pure pain, as the caching of
the passphrase does not work anymore: I need to enter it TWICE per
mail sent (once to send it out, once for the archive, apparently).

Receiving encrypted mails does not work, at all.

Gnus asks for the passphrase first, then tries to decrypt, does not
provide the pin to GnuPG and then decides that it cannot decrypt.

Here is the buttonized output:

-----------------------------

[GNUPG:] ENC_TO 0000000000000000 1 0
gpg: anonymous recipient; trying secret key B7DB041C ...
CALLING USB_CLEAR_HALT
[GNUPG:] CARDCTRL 3 D2760001240101010001000003500000
[GNUPG:] SC_OP_FAILURE
gpg: anonymous recipient; trying secret key 7DF16B24 ...
[GNUPG:] NEED_PASSPHRASE_PIN OPENPGP 1
gpg: ccid_transceive failed: (0x1000a)
gpg: apdu_send_simple(0) failed: card I/O error
[GNUPG:] SC_OP_FAILURE
gpg: anonymous recipient; trying secret key 5378AB47 ...
[GNUPG:] SC_OP_FAILURE
gpg: anonymous recipient; trying secret key CAE4B6E9 ...
Bitte entfernen Sie die Karte und legen stattdessen die Karte mit folgender Seriennummer ein:
   D2760001240101000001000000F80000
[GNUPG:] CARDCTRL 1 D2760001240101000001000000F80000
gpg: Sorry, we are in batchmode - can't get input

gpg exited abnormally: '2'

-----------------------------

For your information, the key id 7DF16B24 is the correct key that is
on the card. So it should indeed submit the PIN instead of breaking
off.

I have to say that this is quite annoying and makes Gnus somewhat
unusable right now. I see three potential fixes here:

 a) create clean way to turn off all pgg handling of PIN's or
    Passphrases, turning that part of the operation over to
    gpg-agent.

 b) fix the caching of PINs

 c) fix decryption of messages that are encrypted for SmartCard



CONCEPT BUG:

If you read the above carefully, you will find that indeed there
something strange: a mail gets signed TWICE, apparently, once for
sending, once for archival.

This is bad for use in secure environments (SmartCards count
signatures) and in fact annoying if you enter your PIN every time,
which some paranoid people may feel like doing.

So I wonder: Is there a striking reason to do this?

If not: This seems a concept bug somewhere in the mailcrypt code... 

Regards,
Georg

-- 
Georg C. F. Greve                                       <greve@gnu.org>
Free Software Foundation Europe	                 (http://fsfeurope.org)
Join the Fellowship and protect your freedom!     (http://www.fsfe.org)

[-- Attachment #2: Type: application/pgp-signature, Size: 306 bytes --]

Re: PGG/GPG Integration bug (somewhat nasty & urgent), potential mailcrypt concept bug

[Georg C. F. Greve]

[-- Attachment #1.1: Type: text/plain, Size: 222 bytes --]

 || On Tue, 03 May 2005 10:44:14 +0200
 || "Georg C. F. Greve" <greve@gnu.org> wrote: 

 gg>  b) fix the caching of PINs

Fortunately, I was able to resolve this one myself.

Patch attached.

Regards,
Georg



[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1.2: pgg-gpg.patch --]
[-- Type: text/x-patch, Size: 685 bytes --]

--- pgg-gpg.el.orig	2005-05-03 14:55:30.000000000 +0200
+++ pgg-gpg.el	2005-05-04 12:03:44.000000000 +0200
@@ -99,13 +99,13 @@
   (if (and pgg-cache-passphrase
 	   (progn
 	     (goto-char (point-min))
-	     (re-search-forward "^\\[GNUPG:] GOOD_PASSPHRASE\\>" nil t)))
+	     (re-search-forward "^\\[GNUPG:] \\(GOOD_PASSPHRASE\\>\\)\\|\\(SIG_CREATED\\)" nil t)))
       (pgg-add-passphrase-cache
        (or key
 	   (progn
 	     (goto-char (point-min))
 	     (if (re-search-forward
-		  "^\\[GNUPG:] NEED_PASSPHRASE \\w+ ?\\w*" nil t)
+		  "^\\[GNUPG:] NEED_PASSPHRASE\\(_PIN\\)? \\w+ ?\\w*" nil t)
 		 (substring (match-string 0) -8))))
        passphrase)))
 

[-- Attachment #1.3: Type: text/plain, Size: 226 bytes --]


-- 
Georg C. F. Greve                                       <greve@gnu.org>
Free Software Foundation Europe	                 (http://fsfeurope.org)
Join the Fellowship and protect your freedom!     (http://www.fsfe.org)

[-- Attachment #2: Type: application/pgp-signature, Size: 306 bytes --]

Re: PGG/GPG Integration bug (somewhat nasty & urgent), potential mailcrypt concept bug

[Simon Josefsson]

"Georg C. F. Greve" <greve@gnu.org> writes:

> I have to say that this is quite annoying and makes Gnus somewhat
> unusable right now. I see three potential fixes here:
>
>  a) create clean way to turn off all pgg handling of PIN's or
>     Passphrases, turning that part of the operation over to
>     gpg-agent.

Do `pgg-cache-passphrase' help?

>  c) fix decryption of messages that are encrypted for SmartCard

Can you tell whether this could be solved by a similar simple patch as
the patch you provided for the b) case?

> If you read the above carefully, you will find that indeed there
> something strange: a mail gets signed TWICE, apparently, once for
> sending, once for archival.
>
> This is bad for use in secure environments (SmartCards count
> signatures) and in fact annoying if you enter your PIN every time,
> which some paranoid people may feel like doing.
>
> So I wonder: Is there a striking reason to do this?

Yes, although somewhat obscure.

The encoding done for archiving purposes is not necessarily the same
as is used for outgoing mail.  It is the same if you mail and post a
message, there is one set of MIME rules for mail and another for news.
Gcc'ed messages might have attachments striped etc, so may be rather
different from what is actually sent.

While that is an explanation, I completely agree that the resulting
situation is sub-optimal.

Some solutions:

Use bcc.  Ugly workaround, but guarantee that you archive exactly what
was mailed (not posted though, since that could be different).

In the GCC handling, make Gnus notice whether the MIME-prepared
message, before PGP signing, is identical to the MIME-prepared message
that was used as input to PGP signing when sending the e-mail, and in
that case store the mailed copy rather than signing another copy of
the identical message.

>  gg>  b) fix the caching of PINs
>
> Fortunately, I was able to resolve this one myself.

Applied, thanks!

Re: PGG/GPG Integration bug (somewhat nasty & urgent), potential mailcrypt concept bug

[Georg C. F. Greve]

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

Dear Simon,

 || On Mon, 09 May 2005 21:25:27 +0200
 || Simon Josefsson <jas@extundo.com> wrote: 

 >> a) create clean way to turn off all pgg handling of PIN's or
 >> Passphrases, turning that part of the operation over to gpg-agent.

 sj> Do `pgg-cache-passphrase' help?

Not really.

This only stops pgg from remembering the passphrase, not from asking
for it and trying to submit it.

pgg should completely IGNORE anything to do with pass phrases and not
submit any pass-phrase related command line options (save those
dealing with gpg-agent) for the gpg-agent to work properly.


 >> c) fix decryption of messages that are encrypted for SmartCard

 sj> Can you tell whether this could be solved by a similar simple
 sj> patch as the patch you provided for the b) case?

This seems to solve the problem with the PIN, yes.

The other problem did not seem Gnus, but actually GnuPG related.

So we can close this problem here.


 >> [ARCHIVAL DOUBLE-SIGNING]
 >> So I wonder: Is there a striking reason to do this?

 sj> Yes, although somewhat obscure.

 sj> The encoding done for archiving purposes is not necessarily the
 sj> same as is used for outgoing mail.  It is the same if you mail
 sj> and post a message, there is one set of MIME rules for mail and
 sj> another for news.

Just to make sure I understood:

So the reason is that Gnus expects Mail archives in News encoding
regarding the MIME rules used? That seems odd. Aren't Mail and News
stored in different folders, usually?

Does this not defy much of the purpose of the archive, which is
supposed to archive what you _actually_ sent, and not something that
is a recoded version of that.

Whenever I had problems with someone telling me that a signed mail did
not verify and I ask myself where the problem is, I have been looking
into the archive, assuming this was an archived version of the mail I
sent. No wonder I could not reproduce the problems.


 sj> Gcc'ed messages might have attachments striped etc, so may be
 sj> rather different from what is actually sent.

That sounds interesting. I had not heard of it before, did not see it
in the archival part of the info file...


 sj> Some solutions:

 sj> Use bcc.  Ugly workaround, but guarantee that you archive exactly
 sj> what was mailed (not posted though, since that could be
 sj> different).

Yes, this is ugly.

I will have to think about using this.


 sj> In the GCC handling, make Gnus notice whether the MIME-prepared
 sj> message, before PGP signing, is identical to the MIME-prepared
 sj> message that was used as input to PGP signing when sending the
 sj> e-mail, and in that case store the mailed copy rather than
 sj> signing another copy of the identical message.

This seems optimal.

Unfortunately I have no idea how to approach this -- and probably
won't find the time anytime soon. Will anyone take this on?

Regards,
Georg

-- 
Georg C. F. Greve                                 <greve@fsfeurope.org>
Free Software Foundation Europe	                 (http://fsfeurope.org)
Join the Fellowship and protect your freedom!     (http://www.fsfe.org)

[-- Attachment #2: Type: application/pgp-signature, Size: 306 bytes --]

Re: PGG/GPG Integration bug (somewhat nasty & urgent), potential

[Werner Koch]

On Wed, 11 May 2005 11:11:32 +0200, Georg C F Greve said:

> pgg should completely IGNORE anything to do with pass phrases and not
> submit any pass-phrase related command line options (save those
> dealing with gpg-agent) for the gpg-agent to work properly.

The way to do this is by checking the $GPG_AGENT_INFO.  If it has been
set there won't be any need to ask for the passphrase at all. 


Salam-Shalom,

   Werner