Re: [gpg] migrate to new gpgme lib?

[Albrecht Dreß <albrecht dress arcor de>]

Am 31.07.03 22:02 schrieb(en) Jacob Perkins:
> You have previously mentioned that balsa would probably use a 'Key Server
> Receive' control if available. Are there any other components or

Triggering the key retreival from a server within seahorse would be 
mega!!! The current interface (just launching gpg in backgroud) works, but 
that's the best you can say about it...

> controls
> balsa might use if seahorse provided them?
> 
> Here are some I am considering that may be useful for balsa:
> 
> * A global context (GNOME/GPG/Context) that extends EventSource and
> provides a method for getting a CORBA_any whose _value is a gpgme_ctx_t.
> Progress related callbacks would be forwarded through the EventSource,
> and
> a passphrase callback would already be connected.

First I should tell you that I do not have the slightest idea about the 
CORBA interface, so I really can't imagine how it would fit into the 
current framework... :-(

IMHO, a centralised passphrase callback/dialog with a cache would be a 
good idea. I tried to make the cache at least half-secure (by symetrically 
encrypting the cached passphrases and only remembering the md5 hashes of 
user id's; maybe you can use it?), but of course having it at only *one* 
place should be safer.

An other point would be a some "key selection interface" which accepts e.
g. the email address and returns the approriate key (if there is only one 
suitable) or displays a list from which the user can select one (if more 
than one key matches the mail address). I must admit, though, that up to 
now I never used the corresponding dialog I built into balsa.

I don't think that moving the decryption/encryption process itself to 
seahorse makes much sense, as it's only a tiny part of the rfc2440/3156 
code in balsa. The bulk of it deals with the interaction with libmutt & 
friends and with gui issues...

> * A signature status control that will show the status of the last verify
> operation. If the signing key does not exist, the Key Server Receive
> control would be presented.

Currently this data is copied after verification into a private structure 
linked to the mail body, which is then displayed or printed. This is not a 
big deal, so I'm happy with the current solution. Of course there is still 
room for improvement, as it's annoying to browse through a mailing list 
with many missing keys, which every time pops up the message box to 
retreive the key. However, I did not find a consistent way to handle both 
RFC3156 (here I could just move the retreive key button to the signature 
part) and RFC2440 messages (they are just text) yet.

> * A key properties control that shows basic properties and has trust
> editing and key signing. This could be launched from the signature status
> control.

Maybe from the context popup in the tree view when the user clicks on a 
signature? Sounds like a good idea to me, even if it's not *so* important.

> Thanks for your input,

You're welcome!

Cheers,

	Albrecht.


-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  Albrecht Dreß  -  Johanna-Kirchner-Straße 13  -  D-53123 Bonn (Germany)
        Phone (+49) 228 6199571  -  mailto:albrecht.dress@arcor.de
_________________________________________________________________________

PGP signature