56052 - Support PGP in PSM

Status: RESOLVED WONTFIX

(Core Graveyard :: Security: UI, enhancement, P3)

Description

[Brian Hunt]

There is no slated PGP support in the PSM, as far as I can tell.  I'm going to
have a look at integrating GnuPG code (initially) unless someone has a better
idea.  Suggestions are welcome as to what sort of PGP we should be aiming for,
RFC2440 (OpenPGP)?

Regards

Comment 1

[John Unruh]

Enhancement.

Comment 2

[Brian Hunt]

It looks as though directly integrating GnuPG code is not an option (since GPL
and MPL are not compatible licenses), however a PGP wrapper may be an option.

The following seem to be the best options available:
* Design a GPL'd module separate from the PSM but which take advantage of hooks
in the PSM (to integrate seamlessly) that is based on GnuPG code.

* Rewrite new PGP code directly in/based on the PSM.

Comments/suggestions are appreciated.

Comment 3

[Javier Delgadillo]

Adding lord to cc list.

Comment 4

[timeless]

1. As is, no GPL code should be considered. If you intend to write a wrapper it 
should be LGPL if you need gpl compatability.
2. Please fix this for All platforms. Generally back end code should be c++, 
and front end should be chrome [xul/js]. The actual hooks to pgp should be 
capable of accepting pgp on any platform.

Comment 5

[Brian Hunt]

Werner Koch has written a PGP patch against M17.

>the patches against M17 are available at
>
>ftp://ftp.openit.de/devel/mozilla/m17-gpg-2000-09-28.diff.gz (57k)
>
>they are against the CVS version from Sep 28th and might or might
>not work.  IIRC, you have to hit SendLater and the message will be
>encrypted to Lima and Mike (Demo keys from GnuPG).  Please removed
>the passphrase from these secret keys first.
>
>There are 2 check boxes in the preferences to enable encryption.
>
>No user Interface however and ugly attachments are displayed.

Not confirmed yet, and preliminary, but useful to have a working version on
reference.

Comment 6

[Alec Flett]

adding self to CC
also adding scc because we've talked about this before, and I know he likes pgp

Comment 7

[Ben Bucksch (:BenB)]

I'll attach the patch to bug 22687, because it doesn't eevn touch PSM. It hacks
the stuff into msgSend et al.

Comment 8

[Javier Delgadillo]

adding lord to cc list.

Comment 9

[Ben Bucksch (:BenB)]

Nevermind.
Problems I see with the patch:
- Hacked into MsgSend
  IMO, our interfaces shouldn't know anything about gpg. More details will
  follow.
- No usage of Mozilla infrastructre
  Uses FILE, fput etc.
- Against a local M17 tree, so it most likely won't apply. Also, lots of trash
  (|Makefile|s etc.) in the patch.

I'll post to .mail-news about what I envision. Link will follow.

Comment 10

[Ben Bucksch (:BenB)]

Posted my suggested esign to
<news://news.mozilla.org/[e-mail]>.

timeless, I'm not sure about your point 2. The GPG glue library (PGG?) might be
only available for Unix. I don't know of any secure ways to interface in a
cross-platform way with GPG and possibly even PGP. Assuming I am right, we could
implement two GPG/PGP backend interfaces - one (secure) for GPG/Unix and one
(insecure) XP.

Comment 11

[Ben Bucksch (:BenB)]

> - Against a local M17 tree, so it most likely won't apply. Also, lots of trash
>   (|Makefile|s etc.) in the patch.

I jsut read on gnupg-devel that the patch is against a 2000-09-28 tree and
pre-alpha (I guessed so - I don't think, Werner Koch had left so much trash in
there otherwise :) ).

Comment 12

[Brian Hunt]

This should be a fairly simple patch to the Mail/News system, but I think it might be a non-trivial patch to the PSM since we probably want general verification and authentication functions in the Mozilla API.

Flagging as [help wanted] :-).  The general scenario should be simple (and was pointed out elsewhere), but it has become clear that the PGP function set has to be internal and cross platform.  That somewhat eliminates gnupg and pgp -- it is possible to go with command line functionality, but I'm somewhat wary of that (unless someone is willing to vouch for the viability of that).

The KDE project's kmail, although relying on external functionality (gnupg, pgp), has the fundamental concept down quite well, and may serve as a useful reference.

Cheers!

Comment 13

[Ben Bucksch (:BenB)]

> That somewhat eliminates gnupg and pgp

? Do you suggest we write our own PGP crypto functions?

Comment 14

[Alec Flett]

Goodness no!
We certainly don't need our own, and if PSM is extensible enough, then we can
simply plug in some glue that makes PSM talk to PGP/GNUPG.. I mean, look at
psm-glue - that's just glue code to make mozilla talk to the out-of-process
PSM.. if PSM itself can be out-of-process, there's no reason we can't write some
glue to do in- or out-of-process PGP as well.

Comment 15

[Chris Charabaruk]

Adding self to cc...
Should have some rudimentary pgping by 1.0. What I wonder though is keyring
maintainance. I don't think the address book is made to be able to add things
like keys or certificates to it. Of course, if I'm wrong, correct me.

Comment 16

[Marcus Pallinger]

FYI, before implementing anything, you may want to check out bug 22687.

Comment 17

[Bob Lord]

A couple of points:  
-PSM 2.0 work is in progress.  I would recommend looking to PSM 2.0 rather than 1.x.
-We'll be adding S/MIME back into the mail client at some point (the library is
already on Mozilla). We'll need to find a way to work together.

Comment 18

[John Unruh]

Milestone 2.1

Comment 19

[Nicolás Lichtmaier]

Don't discard approaching the GnuPG guys and asking
them to allow for a GNU GPL exception or re-release
the code under a dual license (GNU GPL-MPL).

Comment 20

[Stephane Saux]

remove nsenterprise

Comment 21

[Peter Lairo]

This is probably the most important new feature in Mozilla. Unsecure email is
the biggest embarassment to the internet. Imagine the bonus points over M$ OE
this could bring to Mozilla. Please don't drop the ball on this one, get it out
by 1.0 latest. Add some keywords, set the priority, set a target milestone. Please.

Comment 22

[John Unruh]

Mass assigning QA to ckritzer.

Comment 23

[Garth Wallace]

Bug #68702 is for support for anonymous pipe IPC in XPCOM. Would that 
functionality be helpful in fixing this bug?

Comment 24

[Ben Bucksch (:BenB)]

Yes, but there are alternative (IMO better) ways to interface with PGP/GnuPG.

Comment 25

[Jacek Piskozub]

Was the summary change intentional? Probably so as I see references to IPC in
the comments. However, I do not see a patch here so I'm not sure...

Adding "(was: PGP support)" to avoid unnecessary dups.

Comment 26

[Jacek Piskozub]

 I now realized this bug received attributes of bug 68702 when Andre added
himself to CC: Seems Ben beat me to restoring the original values. Thanks.

Comment 27

[Christopher Aillon (sabbatical, not receiving bugmail)]

*** Bug 110608 has been marked as a duplicate of this bug. ***

Comment 28

[Mikko Virkkilä]

Is there any status report for this bug? (Sorry for the spam)

Comment 29

[Kai Engert [:KaiE:]]

My understanding is:

- PGP can't be integrated due to incompatible licenses
- it was suggested to code a wrapper around GPG command line executables
- such a wrapper already exists, see http://enigmail.mozdev.org/
- there is also dicussion in progress in bug 22687, which talks about improved
support for the PGP plugin.

Is it reasonable to mark this bug as wontfix?

Comment 30

[Ben Bucksch (:BenB)]

I still think that this would be a worthwhile improvement. 2 reasons (not all
are necessarily true, depends on the implementation):
- Providing a unified UI, esp. in Mailnews, would be very useful, in order not
to confuse users. I don't know, if that is planned in bug 22687, but I think
that PSM would be a good place for the unified APIs (covering both PGP and S/MIME).
- Yes, enigmail depends on the gpg executable. It is not a violation of licenses
due to the way gpg is invoked, but it still means that GPG is covered by the GPL
license, which adds an additional license for users to read and care about when
evaluating the licenses while downloading or reusing Mozilla(-derivates). I an
mot sure, if this is actually a problem. If it is, the only way out would be to
reimplement OpenPGP in PSM/NSS, just like GPG seems to implement S/MIME.
I might be wrong, in which case this would be a wontfix, but I wouldn't be so
quick with closing this.

Comment 31

[alanjstr]

How is different from bug 22687?  Both would be solved if enigmail was
incorporated, right?

Comment 32

[Ben Bucksch (:BenB)]

Enigmail has nothing to do with PSM.