RE: [Evolution-hackers] Incorrect GPG handling



And what about the chapter right after your quote:
6.2  Combined method

   Versions 2.x of PGP also allow data to be signed and encrypted in one
   operation.  This method is an acceptable shortcut, and has the
   benefit of less overhead.  The resulting data should be formed as a
   "multipart/encrypted" object as described above.

   Messages which are encrypted and signed in this combined fashion are
   REQUIRED to follow the same canonicalization rules as for
   multipart/signed objects.

   It is explicitly allowed for an agent to decrypt a combined message
   and rewrite it as a multipart/signed object using the signature data
   embedded in the encrypted version.


If it is acceptable, shouldn't Evolution at least try to support the reading
of these messages?

Kind regards


________________________________________
From: evolution-hackers-admin lists ximian com
[mailto:evolution-hackers-admin lists ximian com] On Behalf Of Not Zed
Sent: donderdag 13 mei 2004 3:31
To: sroose
Cc: evolution-hackers lists ximian com
Subject: Re: [Evolution-hackers] Incorrect GPG handling

On Wed, 2004-05-12 at 11:20 +0200, sroose wrote: 

You can ignore my last mail. KMail worked fine the regular way.

But I have done further investigation and have found the difference in use
of 
GPG. This is probably the reason for the error.

The following is tested with Thunderbird an Evolution but goes for several 
other clients too.

The mail seems to be formatted in almost the same way. However, when i save 
the GPG encrypted blocks to decrypt them by commandline i get this:

* for a mail send by evolution
--gpg output
	gpg: encrypted with 2048-bit ELG-E key, ID 51B9BF6E, created
2004-05-11
 	    my name etc
--decrypted message
	Content-Type: multipart/signed; micalg=pgp-sha1;

	protocol="application/pgp-signature";
	boundary="=-U65lbm6++U+r75iGceBc"

	--=-U65lbm6++U+r75iGceBc
	Content-Type: text/plain
	Content-Transfer-Encoding: quoted-printable

	TEST

	--=-U65lbm6++U+r75iGceBc
	Content-Type: application/pgp-signature; name=signature.asc
	Content-Description: This is a digitally signed message part

	-----BEGIN PGP SIGNATURE-----
	Version: GnuPG v1.2.4 (GNU/Linux)

	iD8DBQBAoeMbZQGNQ0/97JgRAnfIAJ9DzJl29oB3FTQqygC6uOCm6RLKEACgxpWx
	7IqDQ0aAI4fa0ch6PUiROM4=
	=f78Z
	-----END PGP SIGNATURE-----

	--=-U65lbm6++U+r75iGceBc--



* for a mail send by evolution
--gpg output
	gpg: encrypted with 2048-bit ELG-E key, ID F5FDF3CE, created
2004-05-03
     		sender's name etc
	gpg: encrypted with 2048-bit ELG-E key, ID 51B9BF6E, created
2004-05-11
 		my name etc
	gpg: Signature made Wed May 12 10:56:50 2004 CEST using DSA key ID
1C44307A
	gpg: Good signature from "sender's name etc

--decrypted message
	Content-Type: text/plain; charset=us-ascii; format=flowed
	Content-Transfer-Encoding: 7bit

	test

Conclusion:
Evolution does not 'encrypt and sign' the message but 'encrpyts the signed 
message'.
Is it possible to create a fix to make Evolution compatible with both ways
of 
use?
No.  And to clarify this point, from rfc 3156:

6.1.  RFC 1847 Encapsulation

   In [2], it is stated that the data is first signed as a
   multipart/signature body, and then encrypted to form the final
   multipart/encrypted body.  This is most useful for standard MIME-
   compliant message forwarding.

There is a reason for doing it this way, and it has security implications,
although I can't find the reference to this information.

Here's a very detailed discussion on the topic i found with a simple google
search:
http://world.std.com/~dtd/sign_encrypt/sign_encrypt7.html

A key quote:
"Of course, Encrypt-then-Sign isn't very useful anyway, because only the
illegible ciphertext, not the plaintext, would be non-repudiable. In what
follows, for simplicity, we'll mostly ignore Encrypt & Sign, and we'll
concentrate on analyzing and fixing Sign & Encrypt's defects."

But then it goes on to say pgp later has a sign then encrypt thing - but
afaik that is only inline pgp, which evolution doesn't support anyway.

I'm not sure what your bug report is about.  Is it not displaying the
security information at all/properly?

I would find it odd if all other clients did it differnetly, given the above
quote from the relevent rfc which is pretty unambiguous about it.  And
wouldn't mind knowing why.




Op Wednesday 12 May 2004 10:53, schreef sroose:
> I have noticed another remarkable thing, which might lead to a solution:
>
> When i exported a mail received from a KMail user with 'save as', delted
> the file from my inbox, and imported the file back to the inbox from the
> file, everything was ok. Signature icon displayed as it should.
>
> I did not change the file in any way.
>
> Kind regards
>
> Op Wednesday 12 May 2004 09:54, schreef sroose:
> > Evolution seems to handle GPG encypted + signed messages incorrectly.
> >
> > The problem arises only when the message is encrypted AND signed
> >
> > A mail from other clients (tested with Thunderbird and Windows GPGRelay)
> > which are encrypted and signed with GnuPG do not have the signature
icon.
> > Also the only way to know the message was encrpyted is that set
'remember
> > paasword' off, so by typing your passphrase you know it was encrypted.
> >
> > Is it possible to fix this? I'm willing to make a patch myself if nobody
> > else does, but I've no experience in patching and little knowledge of C
> > and Corba.
> >
> > Kind regards
> >
> > Sam
> > _______________________________________________
> > evolution-hackers maillist  -  evolution-hackers lists ximian com
> > http://lists.ximian.com/mailman/listinfo/evolution-hackers
>
> _______________________________________________
> evolution-hackers maillist  -  evolution-hackers lists ximian com
> http://lists.ximian.com/mailman/listinfo/evolution-hackers
_______________________________________________
evolution-hackers maillist  -  evolution-hackers lists ximian com
http://lists.ximian.com/mailman/listinfo/evolution-hackers

Michael Zucchi <notzed ximian com>

Ximian Evolution and Free Software Developer 


Novell, Inc. 






[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]