Closed Bug 56052 Opened 24 years ago Closed 8 years ago

Support PGP in PSM

Categories

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

Product:
Core Graveyard
Component:
Security: UI
Version:
1.0 Branch
Type:
enhancement

Tracking

(Not tracked)

Status:
RESOLVED WONTFIX
Milestone:
Future

People

(Reporter: bmh_ca, Assigned: bmh_ca)

References

(
URL
)

Details

(Keywords: helpwanted) 

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
Enhancement.
Status: UNCONFIRMED → NEW
Ever confirmed: true
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.
Status: NEW → ASSIGNED
Adding lord to cc list.
Blocks: pgp
OS: Linux → All
Hardware: PC → All
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.
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.
adding self to CC
also adding scc because we've talked about this before, and I know he likes pgp

I'll attach the patch to bug 22687, because it doesn't eevn touch PSM. It hacks
the stuff into msgSend et al.
adding lord to cc list.
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.

Posted my suggested esign to
<news://news.mozilla.org/39E7D2D7.80701@bucksch.org>.

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.
> - 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 :) ).
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!
Whiteboard: [help wanted]
Keywords: helpwanted
Whiteboard: [help wanted]
> That somewhat eliminates gnupg and pgp

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

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.
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.
FYI, before implementing anything, you may want to check out bug 22687.
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.

Milestone 2.1
Target Milestone: --- → 2.1
Version: unspecified → 2.1
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).
Keywords: nsenterprise
remove nsenterprise
Keywords: nsenterprise
Target Milestone: 2.1 → Future
Version: 2.1 → 2.0
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.
Mass assigning QA to ckritzer.
QA Contact: junruh → ckritzer
Bug #68702 is for support for anonymous pipe IPC in XPCOM. Would that 
functionality be helpful in fixing this bug?
Yes, but there are alternative (IMO better) ways to interface with PGP/GnuPG.
Blocks: advocacybugs
QA Contact: ckritzer → junruh
Blocks: protozilla
No longer blocks: pgp, advocacybugs
Keywords: helpwanted → mozilla1.0, patch, review
QA Contact: junruh → benc
Summary: Support PGP in PSM → [RFE] Implement inter-process communication (IPC) in Mozilla
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.
Summary: [RFE] Implement inter-process communication (IPC) in Mozilla → [RFE] Implement inter-process communication (IPC) in Mozilla (was: PGP support)
Blocks: pgp, advocacybugs
No longer blocks: protozilla
Keywords: mozilla1.0, patch, review → helpwanted
QA Contact: benc → junruh
Summary: [RFE] Implement inter-process communication (IPC) in Mozilla (was: PGP support) → Support PGP in PSM
 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.

*** Bug 110608 has been marked as a duplicate of this bug. ***
Is there any status report for this bug? (Sorry for the spam)
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?
URL: http://enigmail.mozdev.org/
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.
Blocks: majorbugs
QA Contact: junruh → bmartin
How is different from bug 22687?  Both would be solved if enigmail was
incorporated, right?
Enigmail has nothing to do with PSM.
Product: PSM → Core
No longer blocks: majorbugs
QA Contact: bmartin → ui
Version: psm2.0 → 1.0 Branch
Status: ASSIGNED → RESOLVED
Closed: 8 years ago
Resolution: --- → WONTFIX
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.