Mozilla+GnuPG (was: Mail clients)

Werner Koch wk@gnupg.org
Sat Jun 9 12:35:02 2001


--=-=-=

 || On Fri, 08 Jun 2001 11:07:22 -0700
 || Christopher Maujean <cmaujean@premierelink.com> wrote: 

 cm> A related question: any news on a Mozilla/Gnu swl> Hello,

Bernd Rausch has worked on this and the latest patch for Moz 0.9 looks
pretty nice.  There is still a lot of work to do.

 http://www.telematik.informatik.uni-karlsruhe.de/~rausch/

The website is in German, but you can just grab the patch for 0.9 and
apply it to that Mozilla version.  I attach the README file which is
in German but maybe someone can take some time and translate it.

If you want to discuss this, please carry it over to gnupg-devel.

Ciao,

  Werner

-- 
Werner Koch        Omnis enim res, quae dando non deficit, dum habetur
g10 Code GmbH      et non datur, nondum habetur, quomodo habenda est.
Privacy Solutions                                        -- Augustinus


--=-=-=
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: attachment; filename=README.pgpmime
Content-Transfer-Encoding: quoted-printable
Content-Description: Mozilla patch for GnuPG

PGP-Mime Patch fuer Mozilla 0.9

Dieser Patch ist schlecht getestet, aus Zeitmangel und wegen schoenen Wette=
rs. Er sollte aber trotzdem funktionieren :-)

PGP-GLUE
Es wird ein neues Modul (/extensions/gpg-glue) in Mozilla eingefuegt, dass =
ueber XPcom ansprechbar ist und alle kryptografischen Funktionen bereitstel=
lt. Es tut dies, indem ein installiertes GPG uber popen aufgerufen und dann=
 die Ausgabe ausgewertet wird. Das ist eine ziemlich schlechte Methode, so =
schnell wie moeglich sollte auf PGPme oder aehnliches umgestiegen werden, a=
ber es funktioniert einigermassen.

EINSTELLUNGEN
In den Preferences gibt es unter "Mail&News" ein neues Tab fuer GPG. Einste=
llungsm=F6glichkeiten sind
-standartverzeichnis f=FCr tempor=E4re Dateien, Trennzeichen ist der Slash =
("/"), ein abschliessender Slash ist Pflicht
-standartbenutzer ist optional
-ist geheimer schluessel durch mantra gesch=FCtzt
-verhalten beim senden (immer/manchmal/nie verschl=FCsseln/signieren)
zum Verhalten beim empfangen gibt es keine Einstellungen, es wird bei entsp=
rechendem MIME-type immer versucht zu entschluesseln bzw. die Signatur zu p=
ruefen.

MAILS EMPFANGEN
Es gibt 3 neue Klassen in Mozillas MIME-Parser
-mimemenc  (MimeMultipartEncyrpted)
-mimeegpg  (MimeMultipartEncryptedGPG)
-mimesgpg  (MimeMultipartSignedPGP, die Klasse MimeMultipartSigned ist scho=
n in Mozilla enthalten)
Falls eine Mail mit entsprechenden MIME-Type empfangen wird (wird in mimei.=
cpp festgestellt), wird automatisch versucht, sie zu entschluesseln ode die=
 Signtur zu pruefen. Gelingt dies nicht, wird die Mail entweder als Textnac=
hricht behandelt (beim entschluesseln) oder es wird eine Nachricht der Form=
 "GPG Signature Status: Could not verify Signature" (beim Ueberpruefen) ang=
ezeigt.
Irgendwann soll es auch moeglich sein, explizit eine Mail zu entschluesseln=
, siehe dazu BUGS, aber im Moment ist das nicht moeglich. Tritt beim entsch=
luesseln ein Fehler auf (zB falsches Mantra angegeben), muss man eine ander=
e Mail auswaehlen und danach noch einmal die urspruengliche, damit der MIME=
-Parser noch einmal von vorne anfaengt, die Mail zu parsen.

MAILS SENDEN

Ich beschreibe nur das Verschluesseln, das Signieren erfolgt analog dazu.
in den Preferences kann man einstellen, ob immer verschluesselt(2), gefragt=
(1) oder nie verschluesselt(0) werden soll. Sendet man eine Mail und ist (1=
) oder (2) ausgewaehlt, wird in MsgComposeCommands.js:() ueberprueft, ob fu=
er alle Empfaenger Schluessel vorliegen. Falls nicht, wird gefragt, ob die =
Mail unverschluesselt oder gar nicht gesendet werden soll. Ist (1) und alle=
 Schluessel da, wird gefragt, ob verschluesselt werden soll. Soll verschlue=
sselt werden, werden die Empfaenger in nsMsgCompFields eingetragen, die um =
entsprechende Attribute und Methoden erweitert wurde (das koennte man sich =
sparen und die Werte erst spaeter aus den Preferences auslesen. Aber diese =
verschachtelten Abfragen habe ich lieber in JS programmiert als spaeter dan=
n in C++).
In nsMsgSend:DeliverMessage() wird ueberprueft, ob es einen GPG-Empfaenger =
gibt. Wenn ja, wird die Mail in 2 tempFiles geschrieben: einer davon wird n=
icht verschluesselt (Header-Felder wie from: to: subject:), der andere wird=
 verschluesselt (inhalt der mail und Header-Felder wie Content-type). Es wi=
rd das GPG-Modul aufgerufen udn anschliessend eine RFC2015 konforme Nachric=
ht aus den verschluesselten und unverschluesselten Nachrichten gebaut. Dana=
ch bekommt Mozilla wieder die Kontrolle und verschickt die Nachricht.
Soll verschluesselt und Signiert werden, wird eines nach dem anderen gemach=
t, nicht die kombinierte Methode benutzt.
=20
BUGS
Dieser Patch ist weit davon entfernt bugfrei zu sein, das liegt hauptsaechl=
ich daran, dass ich Java programmieren gewohnt bin, deshalb ist Speicher al=
lokieren und wieder freigeben nicht meine Lieblingsbeschaeftigung. Ich denk=
e aber, ich habe die groebsten Abstuerze beseitigt. Zudem gibt es einige Fe=
hler (siehe Mails signieren), die ich mit einigem Zeitaufwand vielleicht au=
ch finden wuerde, aber Leute, die schon oefter damit zu tun hatten, bestimm=
t viel schneller finden.

-Falsches Signieren
 Wenn die RFC2015 Nachricht zusammengebaut wird, wird dadurch die Signatur =
ungueltig, also ist im Moment das Signieren von Nachrichten sinnlos.

-MIME-Parser bei kombinierter Methode
 Wird eine verschluesselte und signierte Nachricht empfangen, die mit der k=
ombinierten Methode erzeugt wurde, wird die Signatur unterschlagen, weil nu=
r mimeegpg und nicht mimesgpg aufgerufen wird.

-MIME-Parser bei verschluesselten Mails
 Der MIME-Parser erzeugt bei verschluesseltern Mails 3 Attachments, die nic=
ht in der Nachricht vorhanden sind, Fehler liegt wohl irgendwo in mimemenc,=
 nicht in mimeegpg, aber ich kam noch nicht dazu ihn zu suchen. Ausserdem m=
uss man fuer jedes Attachment ein Mantra angeben. Theoretisch sollte ein ei=
nziges Mal reichen...=20=20=20

-Fehlerbehandlung in nsMsgSend
 Die Fehlerbehandlung ist ziemlich einfach, wenn ein Fahler auftritt return=
 NS_ERROR_FAILURE. Da sollte man vorher noch ein bisschen aufraeumen, tempf=
iles loeschen und was so dazugehoert.

-COPY Makro
 Es gibt im GPG-Modul ein COPY Makro (wie im XPconnect FAQ), aber manchmal =
kopiert der Aufruf zu viel Zeichen, was in der Ausgabe haesslich (und manch=
mal verwirrend) aussieht.

-Mailbody
 Wenn jemand eine verchluesselte Textnachricht schickt (text/plain) waere e=
s schoen, wann man die auf Knopfdruck entschluesseln koennte. Die Funktiona=
litaet dazu ist da, aber ich komme einfach nicht an den Nachrichtenbody.

-Mailadressen
 Mozilla Mailadressen aus dem Adressbuch haben die Form "realname <emailadr=
ess>", aber aus Sicherheitsgruenden akzeptiert dasd GPG-Modul keine Zeichen=
 wie "|", "<", ">" und aehnliche. Man muesste also in GenericSendMessage di=
e Adressen parsen und nur die "echten" emailadressen in nsMsgCompFields eit=
ragen. Vielleicht erledigt sich das Problem auch, wenn kein Code mehr ueber=
 popen ausgefuehrt wird.

-DEBUG Builds
 Im Debug Modus werden keine Temporaeren Dateine geloescht, allerdings ersc=
heinen die Warnungen, dass sensible Daten nicht geloescht werden konnten tr=
otzdem (nicht direkt ein Bug, mehr ein nerviger Umstand)=20=20

-diverse Speicherzugriffsfehler
 Ich bin Java programmieren gewohnt, deshalb koennen durchaus Speicherfehle=
r auftreten, auch wenn ich hoffe, die meisten gefunden zu haben.



LEGAL UND DANK=20
Dieser Patch wurde im Rahmen einer Studienarbeit an der Uni Karlsruhe entwi=
ckelt. Er ist die Weiterentwicklung eines Patches von Werner Koch aus dem l=
etzten Jahr, der Mimeparser und die gpg Aufrufe sind ziemlich komplett uebe=
rnommen, von mir stammt die Oberflaeche und das gpg-Modul.
Falls jemand anderes der Meinung ist, er muesste erwaehnt werden, oder fall=
s es Probleme mit falschen Lizensen gibt, bitte Mail an mich, dann werde ic=
h das so chnell wie moeglich aendern.
Ansonsten sind Weiterentwicklungen und Fehlerberichte erwuenscht und die Be=
nutzung auf eigene Gefahr.=20


Bernd Rausch <b_rausch@web.de>

--=-=-=--