[Gpg4win-devel] GpgOL development background

[Bernhard Reiter]

Dear Friends of GpgOL,

let my give you some background on the development of the new version
of GpgOL - the rewrite leading to version 0.10.x which is included
in the second generation of Gpg4win.

Partly I want to shed light on some difficulties we are facing
and invite your feedback. Gpg4win2 already takes us longer than we 
originally envisioned, but it can do real MIME for OpenPGP and S/MIME
to most common email crypto standards.


GpgOL is loaded as an Exchange Client Extension and - 
to put it simple - it can access Outlook functionality in two ways: 
a) Using MAPI or b) directly dealing with the Outlook object model. 
MAPI function are older, kept compatible over different revisions of Outlook
and often more high level. Microsoft has recently published information 
about "MAPI on the wire" which could help to improve using the 
MAPI functions from within Outlook. We did not fully process the
docs yet - GpgOL development is time and money intensive so we need
to choose carefully where to invest first. Before this docs came to be
it was mainly try and error and it continues to even with the wire
protocol specs at hand.

GpgOL uses MAPI function where it can, but this has limitations.
E.g currently we load the icons using a MAPI function and thus we cannot 
directly use the PNG format for them; there is no parameter were we 
could hand it over. The alternative would be to re-implement our own
replacement function making more use of Outlook internals with all drawbacks.

It is important to keep in mind that GpgOL runs in the main Outlook thread
and it only given control over certain hooks.
The old GpgOL 0.9 only handled (non-MIME) OpenPGP and directly
wrote the result of a decryption into the email window. More complex
feedback requires mostly independent sub-windows.
We believe many Outlook crypto plug-ins work this way.

Simplified Outlook only has internal data structure, which it sometimes
tries to make persistent, either within the .pst or on the Exchange server.
This can happen any time and GpgOL cannot prevent this, only being given
control sparsely. Thus we suspect that cleartext will be made persistent
occasionally if just written into the Outlook data structure.

In order to deal nicely with attachments and the MIME structure,
GpgOL on email-arrival tried to detect crypto emails and 
changes the MAPI message class property.
The prevents Outlook from trying its own S/MIME handler.
To display the attachments the Outlook way, GpgOL 
saves placeholders for the attachments to the email object.
Those placeholder attachments are encrypted with a session key.
The main body is saved in a similar way.

Outlook will display the list of placeholder attachments and if they
are to be viewed or saved, GpgOL gets control again doing the necessary
decryption using it session keys.

However the use of placeholders has a drawback: It only works if Outlook has 
write support on the source of the email object. If it happens to be
a read-only Exchange folder, an error messages comes up. 
Also this might introduce more write access than usual, e.g. over IMAP.

We did evaluate to change the placeholder attachment design to avoid
write access. There would not be a placeholder list for attachments, 
but a button for handling the attachments instead. Info for the attachments
would need to be displayed in an additional window. The window could be
made nicer if other crypto results go in there, more information about
this and attachments from all emails and it could be made a window 
you could keep open during operation on several emails.
Decrypted body and attachments would be saved on disk 
instead of the Outlook object.
As a plus it would make the GpgOL code much simpler.

But early test users have given us the feedback that having a separate
window would be hitting usability hard. More acceptable would be 
a sub-window, integrated in Outlook's main view. 
From the technical site, we believe we cannot do an integrated sub-window
- it is too hard and not robust enough against other plug-ins, languages
and Outlook changes.
So we stick with the current approach of Gpg4Win1.9.13beta for now.

Best Regards,
Bernhard Reiter

-- 
Managing Director - Owner: www.intevation.net      (Free Software Company)
Germany Coordinator: fsfeurope.org. Coordinator: www.Kolab-Konsortium.com.
Intevation GmbH, Osnabrück, DE; Amtsgericht Osnabrück, HRB 18998
Geschäftsführer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 206 bytes
Desc: This is a digitally signed message part.
Url : http://lists.wald.intevation.org/pipermail/gpg4win-devel/attachments/20090210/a0326e54/attachment.pgp