[Evolution-hackers] Developing a GnuPG/Seahorse component for mail clients

[Jos? C. García Sogo]

On Fri, Dec 08, 2000 at 02:06:01PM +0100, Werner Koch wrote:
> Hi!
> 
> On Fri, 8 Dec 2000, jose at jaimedelamo.eu.org wrote:
> 
> >    We want to make a component from it, so it could be included in mail clients 
> > for encryption/decryption of mails.  I have been thinking on the CORBA IDL 
> > interface that should be better for a mail client, and I have realizaed that it 
> 
> Well, some comments from me [Sorry I have not yet come around to
> reply to your mail on the gpg list].
> 
> My current thinking is that I would like to integrate this suff by
> using a libary and actually I already did the verification and
> decryption part but it has to be made better.  Using a libray for
> now is just easier - it should definitely be replaced by a
> component.

   Ok. You do the library and I do the component using this library. Once we have finish both, we can decide wich thing we must use.

>Due to other requirements I have to work first on a COM+
> component for Windwos :-(

  Puff! This must be quite horrible! :-)

> Things which are missing in my code are the obvious ones: Encryption
> and signing because this needs some user interface.  If we can use
> Seahorse for this - good.

  These are my intentions. Write all the needed stuff so integrate GnuPG in mail clients (not only evolution) can be made easily.

> 
> > 	struct Recipient {
> > 		string UserName;
> > 		string KeyID;
> > 	};
> 
> You should not distinuguish between a keyID or a UserName.  Just
> define a User ID and don't care what it is - GPGME will tell you if
> it is not sufficient.

  Perhap yes. If there are some keys with the same userid gpgme will tell me: "You need to specify more". My intention is that if this happens when creating a recipient a new window with all possible keys appears, letting user choose which he wants to use. Once he has chosen which one he wants, we store in KeyID this information. I'm considering doing this internally, not exporting this attribute.

> 
> > 	interface RecipientList {
> > 		void AddRecipient (in Recipient);
> > 		void list ();
> 
> gpgme has such a class too.

    And this is for exporting it :-)

> 
> > 	interface KeyManager {
> > 		void ImportKey (in string UserID);
> > 		void HaveRecipient (in Recipient recipient);
> > 		void ListSecretKeys ();
> > 	};
> 
> I have not yet implemented this.  I don't think that it is a good idea
> to have a notation of a secret key.  It is better to just say: "Key"
> and then check whether a key is capable of signing or decrypting.
> 

   This only inteds to make a list with the userIDs of the secret keys we have in the keyring. I'm going to rethink if it's usefull or not.

> > 	interface Crypto {
> > 		void sign (in string buffer, in Recipient signer, out 
> > signed_buffer);
> > 		void encrypt (in string buffer, in RecipientList recipients,
> > 				 in Recipient signer, out encrypted_buffer);
> > 		void verify (in string buffer, out string clear_buffer, out 
> > string status);
> > 	};
> 
> gpgme has something similiar to this.  However it does not use
> [string] but a GpgmeData object which can we a wrapper around some
> memory or be a file or a stream of dfata.
> 

   I have seen it, but I don't know if I can define `in GpgmeData buffer` in some way in CORBA. Is there any CORBA guru who could clarify this?

> > 	interface Session {
> > 		attribute boolean EncrypToSelf;
> > 		attribute Recipient DefaultUser;
> 
> Some of these things are usefule but don't make it too complicated.
> It might be better to have this as a global property and get/edit it
> in GnuPG options file.

  OK. But this implies editing by hand GnuPG options file. This try to avoid it.

> 
> > 		atrribute boolean RememberPassword;
> > 		attribute int RememberPasswordTimeout;
> 
> Eventually, gpg should handle passwords itself and don't bothre an
> application with it.  This is more secure.  Because I see, that it
> might take some time to get this gpg-agent thing ready, we need a
> way to ask for the passphrase.

  OK. I think it's better. But we need gpg-agent working for this. AS you can see these are only configuration options. As they are exported, mail clients can change this opton without using configure method, which will show a dialog with all this stuff.

> 
> gpgme employs XML in it's interface to return information about keys
> and meta information about signatures.  I think this is the easiest
> way to handle all those attributes.  If it turns out that xml
> parsing gets to complicated we can implement some methods for the
> most common attributes we need to access.

   I think XML is good. We have libxml in GNOME to parse XML files, so I think it won't be very difficult to handle it.

> 
> Back to Windows hacking :-((
>

   Be luck!!