Status

enhancement
20 years ago
3 months ago

People

(Reporter: bpreidecker, Unassigned)

Tracking

(Blocks 2 bugs)

Dependency tree / graph
Bug Flags:
blocking-thunderbird3.0a1 -
blocking-thunderbird3 -
wanted-thunderbird3.0a1 -
wanted-thunderbird3 -

Firefox Tracking Flags

(Not tracked)

Details

()

Attachments

(11 attachments)

Reporter

Description

20 years ago
Hi, I'd appreciate a plugin for PGP to ede and encrypt PGP crypted
messages directly in Mozilla.

Updated

20 years ago
Summary: PGP Plugin → [RFE] PGP Plugin

Comment 1

20 years ago
For reasons associated with U.S. export restrictions, no cryptographic
security of any kind is likely to be included in the original sources
for Mozilla as distributed from the U.S. Netscape will have their own plans
of course for the Navigator 5.0 browser based on Mozilla.

See http://www.mozilla.org/projects/security/ and especially
news://news.mozilla.org/netscape.public.mozilla.crypto for more --
there is no reason cryptographic plugins could not be independently
developed and distributed where it is legal to do so without restrictions.

If there is not already a discussion on PGP for Mozilla mail in that newsgroup,
go ahead and start one.

Updated

20 years ago
Assignee: jefft → nobody

Comment 2

20 years ago
Help wanted.

Updated

20 years ago
Summary: [RFE] PGP Plugin → [HELP WANTED] [RFE] PGP Plugin
Whiteboard: [HELP WANTED]

Updated

20 years ago
Assignee: nobody → nobody

Comment 3

20 years ago
It's actually "nobody@mozilla.org" for help wanted bugs.

Comment 4

20 years ago
As discussed in the crypto newsgroup, I think what is really needed is a generic
plugin architecture which would allow 3rd parties to provide things like a PGP
plugin (if export restrictions/patent problems prevent Mozilla or Netscape from
doing so themselves).  If I understand correctly, for receiving mail this is
part of the MIME handler plugin architecture, but no similar plugin architecture
exists for composing mail.  Anyway, I voe for this.

Updated

20 years ago
Keywords: helpwanted

Updated

20 years ago
Summary: [HELP WANTED] [RFE] PGP Plugin → [RFE] PGP Plugin
Whiteboard: [HELP WANTED]
Some mailers just use stdin/stdout to interface with PGP (i.e. you just enter a
PGP command for en-/decrypting in preferences and mails are passed through it). 

If that is an export restriction violation, I don't know it... But I know, that
encryption in TkRat works this way.

Comment 6

20 years ago
Bulk moving all MailNews Security bugs to new Security: General component.  The 
previous Security component for MailNews will be deleted.
Component: Security → Security: General

Comment 7

19 years ago
What about the more relaxed US crypto regulations nowdays? Would'nt that make it
possible to include crypto as long it is opensource (as in gnupg)?
ryde, propably OK to include crypto or crypto glue code now. Mozilla.org may
need to query the US regulations bureau (don't know its name) for permission.
however. I suggest to just submit code and then let Mozilla.org figure things
out.
There should always be a version of Mozilla available that does not include any
crypto, since some countries have use restrictions and can't have any crypto.

I say this because I expect this to be a desired base feature once implemented.

Comment 10

19 years ago
But lets remember, this would only be a PLUGIN. You would still have to have 
PGPkeys, GPGP or something similar to create and maintain your keys. The plugin 
would only be an interface for such a product, and these are controlled already. 
PGPkeys, last to my knowledge, was guarded by a service NAI was using to make 
sure your hostname was in the U.S. You also had to answer a few questions 
prooving your were a US citizen. Sure you could like, but it wouldn't take them 
long to track you down and prosecute. So, I don't really see how providing a 
plugin to the PGP shell / interface would be against US Export Regulations. 
Anyone? Anyone?

Comment 11

19 years ago
Also adding to this discussion about PGP (I seem to have had the last post, 
too), one can't even use the PGPKeys app for Win32 because the text window is 
non-standard. Isn't there anything someone can do? I know it is virtually 
impossible to create a plugin for ol' Netscape (4.x) because the architecture 
doens't allow for it. No one has made one (I've searched the entire net many 
times and found nothing) and when I took it upon myself to create one, I found 
that there is really no interface to do such because the messages use Composer 
to write and use Navigator to view and since it's driven by MIME types, you 
would need to use text/plain or text/html and test for keywords, but there is 
nothing to really encrypt / sign using the composer functionality. An interface 
into the message window (or any window for that matter) would be great so that 
developers could at least write pgp plugins. The current method is really 
annoying, especially in unices where you have to copy text to a file, 
encrypt/sign it, open it up, copy the text, and paste the results in the email 
overwriting all the text you wrote previously. The current security in Mozilla 
is great, but S/MIME keys are expensive and I think you should really provide a 
means to include the free PGP/GPG that so many more people use anyway for so 
much more! TIA

Comment 12

19 years ago
The issue with S/MIME isn't the cost of key (you can get free ones at 
http://www.thawte.com), but that you cannot generate your own keys on your 
machine. It's a trust thing.
> The current security in Mozilla is great, but S/MIME keys are expensive

There is currently no support for S/MIME in Mozilla Mailnews, nor is it planned
for NS6.

There are interfaces in Mozilla: the libmime MIME converters
<http://www.mozilla.org/mailnews/libmime-content-type-handlers.html> in
mozilla/mailnews/mime and the generic stream converters in
mozilla/netwerk/streamconv. The former already existed in 4.x.

Comment 14

19 years ago
Ummm, so there exists no possibility of any mechanism existing within 
Mozilla/NS6 for having private mail? That's a smart move.
Jerry, yes, it is. The question is: What would you cut otherwise? Threaded view?
Search? Filtering?

Comment 16

19 years ago
That's my point. When it comes to priorities, personal privacy in email has 
always taken a back seat in Netscape and continues to do so in Mozilla. This 
should be in a newsgroup.

Comment 17

19 years ago
I'm interested in implementing this.  From what I can tell it shouldn't be too
hard.  Aside from the libmime docs already linked, is there any other
information that would be pertinant?
Otto, just
<http://lxr.mozilla.org/seamonkey/source/mailnews/mime/src/mimemsig.cpp> and
<rhp@netscape.com> (Maintainer of libmime).

I'm not sure, what the right implementation strategy would be. A simple hack
would be to just use libmime (mimemsig), but the best solution right now seems
to me to route it via libmime <-> generic stream converter in netwerk <-> PSM
<-> NSS - obviously a lot of work.

I'd just ask on .crypto, what the PSM guys (especially Christian Kaiser
<chrisk@netscape.com>, responsible for S/MIME) consider being the best solution.

Comment 19

19 years ago
Sorry for the spam, but has any work been done on this recently.

I have to say, the demand for authentication and encryption is staggering, even
just looking at the vote number for this bug.  I believe the importance of this
functionality may be understated.  (Not to dictate priority, of course!)

Regards
We are aware of the importance of this bug for privacy. Personally, I would
really like to see PGP used for every mail.

However, this is a big feature. Right now, we are busy finishing the basic
features (like mail reading and composing).

If somebody wants to help, just ask.

Comment 21

19 years ago
Although important for privacy, the presence of a fully integrated PGP (or
equiv.) design is inherently valuable to corporate clients for the purposes of
authentication.  It would be of extraordinary value to Netscape to provide the
service of keyserver to corporate clientelle.  In particular, this would provide
an excellent fundamental feature.

I've started work taking GnuPG backwards, but that's not exactly easy, and
attempting to decypher the Mozilla mail/news API at the same time.
Unfortunately I have no experience with programming either GnuPG or Mozilla, but
I'm going to give it a go, so to speak.
Brian, you don't need to look at the Mailnews APIs yet, I think. The best way to
go might be to hook GPG up in PSM, and make it look similar to S/MIME in the app
interfaces.
Thanks for looking into it!

Comment 23

19 years ago
I've opened up Bug 56052 under PSM to deal with graceful PGP handling.  At least
one patch has been written for use between GnuPG and Mozilla.  Further
information forthcoming.

Updated

19 years ago
Depends on: 56052
Damon: very cool.  I'm cc'ing sspitzer and others who can help get this patch
ported, reviewed and checked in.

I don't think the DLL handling needs to be Windows-specified -- have you looked
into using NSPR's PR_FindSymbol and PR_FindSymbolAndLibrary?  See
http://lxr.mozilla.org/mozilla/source/nsprpub/pr/src/linking/prlink.c#1112 and
thereabouts.

Should this bug be reassigned to you?

/be

Comment 26

19 years ago
(long message...sorry)

I apologize for the surprise and suddenness of this code. I have been working as 
a developer for Network Associates on a PGP plug-in for Mozilla for some time, 
and was not aware of the work detailed in this bug until today. I was directed 
by Jean-Francois Ducarroz <ducarroz@netscape.com> to attach the diffs and files 
to this bug, which I have done. Jean-Francois is apparently the libmime module 
owner these days.

The code I wrote basically adds a content type handler and registers itself to 
handle multipart/encrypted, multipart/signed, and plain/text. The idea is that 
the code scans these messages for PGP content, and if it finds any, it attempts 
to process it. If not, it creates a new mime object and passes the message 
along, de-registering itself from the above types temporarily so that the 
default handlers will take over.

I also added an overlay for the Composer window, with a PGP menu in it. This is 
a hard-coded reference in the messengercompose.xul file. I don't yet know how to 
add such a thing dynamically.

Finally, to encrypt and/or sign messages, I added code inside nsMsgSend.cpp, in 
the function nsMsgComposeAndSend::DeliverMessage(), taking the final output of 
the Composer just before it is sent, and applying the appropriate PGP actions. 
This was recommended to me by Richard Pizzarro <rhp@netscape.com>, who was the 
former owner of libmime and I think a Mail/News architect. I apologize if this 
is the wrong way to have done this.

My official concern is to add code to Mozilla that will interface with a PGP 
plug-in provided by Network Associates in our PGP product. However, it would 
certainly be nice and a big bonus to have an interface that would be generic 
enough to allow someone to plug in GPG or any other OpenPGP application and 
still work.

I also would like to make sure that this work doesn't get pulled in two 
different directions. I'm already starting to work with Jean-Francois Ducarroz, 
but I notice that he is not on this bug list, so we should include him in 
coordination with this, I think. That way, the work won't be pulled in different 
directions.

Comment 27

19 years ago
I forgot to mention that this work is not officially supported by NAI yet, so 
please don't bug anyone else at NAI about this, only me. Thanks... :)
Damon: thanks for the history.  I'm reassigning this bug to JF, but you could
take it from him and assign it to yourself.  It's important to reassign it from
nobody@mozilla.org, get its Target Milestone field set, and otherwise own it
well.  I've nominated it for mozilla1.0 target milestone by setting that
milestone keyword.

mozilla.org definitely carries the torch for open plugin APIs, so it should be
possible to plug in an alternative PGP implementation.  We need someone else to
step up and work with your patch, probably once it has been checked in.

One legal-ish nit: I notice many files have NPL1.1 boilerplate license comments,
a few have no license (only a NAI copyright notice), and I didn't look at all
files.  It seems to me you could use the MPL1.1 for all files.  Cc'ing hecker
for advice.

/be
Assignee: nobody → ducarroz
Keywords: mozilla1.0
I just tried compiling this on Linux.  After you get rid of all the ^M in the
source files (they screw with \ escaping newlines) and add the following to
Makefile.in:

EXPORTS
= \
nsPGPModule.h \
nsIPGPModule.h \
$(NULL)

The plugin builds with no problems.

Comment 30

19 years ago
Damon - thank you for implementing this feature.  Do you have suggestions or a
Mozilla QA contact to help you write the test plan to test this particular
feature within Mozilla?   Thanks, Lisa

Comment 31

19 years ago
Re brendan's question on licensing, nobody except Netscape should be using the 
Netscape Public License for their code, so you should change the headers to 
remove the NPL stuff.

This code can be (but need not be -- see below) licensed under the Mozilla 
Public License; C/C++ files can use the boilerplate language at 
<http://www.mozilla.org/MPL/boilerplate-1.1/mpl.c>.

Damon, I'm assuming that even though this is not "official" NAI code, you are 
still creating it in your capacity as an NAI employee; I'm also assuming that 
your employer agreement with NAI is a "work for hire" agreement whereby anything 
you develop in the course of your NAI work becomes NAI's property. Assuming I'm 
right about this, if you use the MPL then the blank spaces in the boilerplate 
text referenced above should be filled in as follows:

* The Original Code field should contain "Plugin interface for PGP/GPG" (or 
whatever other short phrase accurately describes what you've added.

* The Initial Developer field should contain "Network Associates, Inc."

* The Portions created by field should contain "Network Associates"

* The copyright field should reference "Network Associates, Inc."

* There should be nothing under the Contributors line. That gets filled in later 
if/when other people contribute changes; you put their names and email addresses 
there.

The complete MPL 1.1 boilerplate for C/C++ would then be:

/*
 * The contents of this file are subject to the Mozilla Public
 * License Version 1.1 (the "License"); you may not use this file
 * except in compliance with the License. You may obtain a copy of
 * the License at http://www.mozilla.org/MPL/
 * 
 * Software distributed under the License is distributed on an "AS
 * IS" basis, WITHOUT WARRANTY OF ANY KIND, either express or
 * implied. See the License for the specific language governing
 * rights and limitations under the License.
 * 
 * The Original Code is a plugin interface for PGP/GPG.
 * 
 * The Initial Developer of the Original Code is Network Associates, Inc.
 * Portions created by Network Associates are
 * Copyright (C) 2001 Network Associates, Inc.  All Rights Reserved.
 * 
 * Contributor(s): 
 */

(You can word wrap the above as necessary.)

As a final note, NAI doesn't absolutely positively _have_ to use the MPL; it 
could use another open source license, as long as it is compatible with the MPL. 
(The GPL is not compatible, incidentally.) However if NAI doesn't want to use 
the MPL then someone there needs to email staff@mozilla.org and explain what 
license NAI wants to do, after which staff will render an opinion as to whether 
that's OK or not.

Comment 32

19 years ago
Frank, thanks for the detailed explanation. I'll make the header changes as you 
suggested. To the best of my knowledge, NAI has no problem using the MPL for the 
code that is being contributed to Mozilla, so I'll use that.

Boris, thanks for your comments on compiling the code on Linux. I'll make the 
appropriate changes. As you can probably tell, I'm developing this on a Win32 
platform. We definitely need Linux (and other UNIX) and Mac folks to make sure 
the code compiles, because I don't have the resources to test this myself. I 
will always try to ensure cross-platform compatability, but I'll no doubt miss a 
few things. I'll also make sure to run the files through a carriage-return 
stripper next time before attaching them. I'm pretty sure that CVS does 
end-of-line substitution automatically for text files, so hopefully this will be 
a moot point soon.

Comment 33

19 years ago
With regards to a test plan, I don't have any at this time or any QA contact for 
testing, other than the internal testing we will do at NAI. What do I need to do 
for this?

Comment 35

19 years ago
/* -*- Mode: C++; tab-width: 4; indent-tabs-mode: nil; c-basic-offset: 4 -*-

please don't use tabs. since you pick the modeline, you can choose 2 or 4, but 
we request that you follow that setting.

	if (msgCompose)
	{
		var msgCompFields = msgCompose.compFields;
   
        if (msgCompFields)
        {
			if (msgCompFields.GetPGPEncrypt())
			{
please reindent that to something like this:
  if (msgCompose) {
    var msgCompFields = msgCompose.compFields;
    if (msgCompFields) {
      if (msgCompFields.GetPGPEncrypt()) {

please avoid using dump() w/o some pref or setting that makes the dumps not 
happen by default.

i think 				
document.getElementById("menu_pgpEncryptMessage").setAttribute("checked", 
false);
can be written as
document.getElementById("menu_pgpEncryptMessage").checked=false;
-
  nsCOMPtr<nsIMimeObjectClassAccess>  objAccess;
  PRInt32                             rc=-1;
nsresult res = nsComponentManager::CreateInstance(kMimeObjectClassAccessCID, 
NULL,NS_GET_IID(nsIMimeObjectClassAccess),(void**) getter_AddRefs(objAccess)); 
this is probably bad.

instead of using -1, you should probably use an NS_something, but more 

if there's a better way to do the object initialization, i'll let scc or jag 
explain it.

generally, we use nsnull instead of NULL, but this is extern C, i don't know if 
that changes anything.

if we could convert nsIPGPModule.h into an idl file that'd be great, but we can 
do that later.

NS_PRECONDITION(nsnull != aInstancePtrResult, "nsnull ptr");
if (nsnull != aInstancePtrResult)
can be written as
NS_PRECONDITION(aInstancePtrResult, "nsnull ptr");
if (aInstancePtrResult)

generic-style comment:
  leafClass = ((MimeObjectClass*)COM_GetmimeLeafClass());
i don't think you need the extra outer ()

you seem to be mixing PR_Malloc and nsCRT:: functions, i'm not sure that's a 
good idea. jag and scc can comment about various string classes that might be 
of use.

(int*) casts might be ok, but in general we have NS_STATIC_CAST or something 
like that for type conversions ...

<offtopic>
#if defined(_WIN32) && defined(_M_IX86)
#include <windows.h>
#endif /* _WIN32 && _M_IX86 */
this looks like it'd break alpha, mips, ppc and the other platforms win32 
theoretically targets. i guess that's because nai doesn't offer pgp for them?

i was under the impression that winnt alpha had an x86 compatibility layer... 
where mozilla could be compiled for alpha and maybe use x86 plugins, does 
anyone know?

nsPGPModule::FindHeader(char *header_buffer, char *header_str,
                        char **header_start, int *header_length, 
                        char **buffer_end)
the while (1) loop here scares me.

while (1) {
if (*line_end == '\r')
 if (got_cr) { end_of_buffer = PR_TRUE; break; } else got_cr = PR_TRUE;
else if (*line_end == '\n')
 if (got_lf) { end_of_buffer = PR_TRUE; break; } else got_lf = PR_TRUE;
else
 break;
line_end++;
}

the logic appears to be: 
\r\r=>gotcr+end_of_buffer+break,
\n\n=>gotlf+end_of_buffer+break,
\n\r=>gotlf+gotcr+break
\r\n=>gotcr+gotlf+break
anyways, i hope we have a string class that can do whatever this code is doing.

thanks for working on this. if you have questions, someone should be able to 
answer them in #mozilla on irc.mozilla.org
Damon,
assuming you did NOT work closely with a Mozilla developer, I'm impressed by
this code. From a very quick look, you use most of the (somewhat "custom")
Mozilla resources (string functions, XPCOM, XUL etc.), which aren't easy to
figure out.

For the record, we had a discussion on the PGP support architecture back in
October (see <news://news.mozilla.org/39E7D2D7.80701@bucksch.org> and its
thread), but I failed to note that here. It's probably too late now, but you may
want to read it, in case you see some improvements that are not too hard to make
by now. For me, it would be especially important to keep the programming
interfaces and user interface agnostic of encyrption scheme (Open PGP (via PGP
or GPG) or S/MIME). If that is too hard by now, we can always improve it later
(I hope!). Definitely nice to see some OpenPGP support!

Comment 37

19 years ago
Thanks for the continuing comments. Should I attach changes here, or should I 
wait for the code to be checked in via CVS, and then commit the changes that 
way? I don't want to hold up the process of getting this into the repository, 
but I also don't want to clutter up this bug with a bunch of attachments.
dgal: please clutter away, bugzilla.mozilla.org has plenty of disk space.  We
need to engage some review and super-review in a more affirmative fashion too
(like, see r= and sr= stamps of approval in the bug, for a particular patch).

To avoid re-attaching a mostly-unchanged patch, sometimes I show only the diff
to the last patched version of the code (so others who have already applied the
patch can apply the patch-to-a-patch).  Please use diff -u.

Apart from timeless's cosmetic nit-picking (hey, I do that too, although I think
you should be free to use whatever consistent bracing style you like --
timeless, give the man a little freedom!), I'm keen to hear whether you have had
time to try PR_FindSymbol from NSPR (I gave an LXR link last time), instead of
the WIN32 specific code you originally wrote.  It would be one step toward
portability, and the right step (rather than #ifdef'ing for each platform and
recapitulating NSPR's prlink.c code).

/be

Comment 39

19 years ago
Yes, I'm planning to incorporate the prlink functions into the code. I 
definitely want to use as much cross-platform code as possible, and anything 
that's already been written is a definite bonus. I'm also eager to find out what 
the appropriate functions are for string and memory operations (re: mixing 
PR_Malloc and nsCRT::xxx). I based a lot of my code on what was already in 
libmime. It seems to be a mix of old Netscape 4.x code and newer Mozilla code, 
which would explain the inconsistencies.
> It seems to be a mix of old Netscape 4.x code and newer Mozilla code,
> which would explain the inconsistencies.

Right, IIRC, it survived from 3.x. That makes it one of the oldest code parts in
Mozilla. Now that rhp is gone, nobody really knows it, I fear.

Comment 42

19 years ago
The changes look great, however, instead of removing the modline, please 
replace it:
-/* -*- Mode: C++; tab-width: 4; indent-tabs-mode: nil; c-basic-offset: 4 -*-
+/* -*- Mode: C++; tab-width: 2; indent-tabs-mode: nil; c-basic-offset: 2 -*-
You don't need to attach a patch for this change now, it can wait.

Marking patch, review and hoping people will build and test this.
Keywords: patch, review

Comment 43

19 years ago
As a long time and consistent PGP user, I'm very excited about this patch.  I'm
about to go through and review all the string-foo in it.  In the mean time mine
only suggestion is to prefer |do_CreateInstance| over the longer and
non-type-safe direct calls to |CreateInstance|.  More anon.

Comment 44

19 years ago
I have PGP installed on my Mac.  I'll pull and build with these patches to test
as well.  If this works out, I can abandon Eudora forever.

Comment 45

19 years ago
Just so everyone knows, this code will _NOT_ work with any currently released 
NAI version of PGP that you can buy or download, because we have not yet 
released the plug-in for Mozilla. The code attached to this bug simply allows 
a future NAI PGP plug-in, and soon hopefully any other PGP plug-in, to load into 
Mozilla and work. The NAI PGP plug-in that will work with this code will appear 
in a future version of PGP, but at this time I can't nail down what version it 
will appear in.

I'm planning to add some test code that simulates a PGP plug-in. It won't 
contain any hard crypto...probably just ROT-13. The idea is to both provide a 
way to test the plug-in interface code, and to provide a sample so that other 
PGP plug-in developers can see what they need to implement in order to make 
their own PGP plug-in for Mozilla.
If you're going to implement rot-13, could you fix bug 66822 as well? :-)
Yeah, because the ROT13 algorithm is extremely complicated.
Damon, you forget to copy the new member variables you added to nsMsgCompField in the Copy function:

nsresult nsMsgCompFields::Copy(nsIMsgCompFields* pMsgCompFields)
{
	nsMsgCompFields * pFields = (nsMsgCompFields*)pMsgCompFields;

[snap]

  m_pgp_encrypt = pFields->m_pgp_encrypt;;
  m_pgp_sign = pFields->m_pgp_sign;;

	return NS_OK;
}
Very good job Damon, your stuff compile without problem on Mac (after creating the Mac project and added a  
MANIFEST file).
I have one little request. Can you use do_CreateInstance instead of nsComponentManager::CreateInstance in 
nsMsgSend.cpp. For that you need first to define a contract ID in nsPGPModule.h:

#define NS_PGP_MODULE_CONTRACTID \
  "@mozilla.org/mimecth/pgp;1"

and then use the following code instead in nsMsgSend.cpp:

    nsCOMPtr<nsIPGPModule> pgp_module(do_CreateInstance(NS_PGP_MODULE_CONTRACTID, &res));    
    if (!NS_SUCCEEDED(res) || !pgp_module)
      return NS_ERROR_FAILURE;

Also, you want need anymore to define:

static NS_DEFINE_CID(kPGPModuleCID, NS_PGP_MODULE_CID);

Comment 50

19 years ago
I doubt this is still 'helpwanted'.

Comment 51

19 years ago
Very thorough patch :-)  What I examined was the pgp.diff file within the latest
patch.  This still leaves me with the new files to examine, I think.

In the course of reviewing this patch, I was sorry to see that
|nsIMimeContentTypeHandler| and |nsIMimeObjectClassAccess| aren't IDL-ized.
That's not your fault; just something I noted.  They may even be special cases
that shouldn't be IDL-ized ... but I didn't see any comment that supported that.

On to your code.  First, about names: is |m_pgp_sign| better as something like
|m_want_pgp_signature| or |m_pgp_need_signature|, or some other permutation that
better fits its boolean nature?  Similarly |m_pgp_encrypt|, and the member
functions used to get and set these variables.  Admittedly, your names do seem
to fit the style already present in the file, I just wonder if, in this case,
better names are worth going a little inconsistency.

Second, when declaring simple character-sequence literals, they really are
|const|, so prefer that in their declarations, e.g.,

  const char *content_type_str = "Content-Type: ";

If you have to use that string in a function that requires a non-const argument,
you should be concerned :-)  and the compiler should alert you.  If the function
is just misdeclared (e.g., a system function that really doesn't modify the
string) use a |NS_CONST_CAST| at the call-site.  Else if the function really
needed a non-|const| string, now you're happy you caught it.

As previously mentioned, you don't want to call |CreateInstance| by hand.
Prefer |do_CreateInstance|.

Even for |malloc| and friends, prefer new-style casts over old.  New-style casts
catch bugs at compile time, so get in the habit of using them.  A |static_cast|
is supposed to be sufficient for convertion a |void*| to any
(non-pointer-to-member) pointer to another type:

  plain_buf = NS_STATIC_CAST(char*, PR_Malloc(plain_size + 1));

This old-style cast:

  return (void *) MIME_MimeHeaders_new();

shouldn't even be needed (the conversion to |void*| is automatically allowed, I
think), and if it is, you should prefer |NS_STATIC_CAST|.  Prefer
|NS_STATIC_CAST| for the casts back to |MimeHeaders*|, et al, in the remainder
of these external entry points.

My particular preference is to avoid gratuitous multiple |return|s, e.g., use

  return (rc < 0) ? NS_ERROR_FAILURE : NS_OK;

If you don't like |?:|, then use a temporary to be returned at the end.

Hmmm, the code already in these files doesn't abide by our argument naming
convention of beginning with a lower-case 'a', e.g., |aPtr|, |aMimeObject|,
etc., so I can hardly blame you for following their lead.  This is something to
be aware of, though.

That's it.  If you can fix the declarations, casts, use of |CreateInstance|, and
multiple returns; defend or fix member names; consider fixing argument names;
then I'm OK with the diff-ed hunk.  Now I'm off to look at your new files.

Comment 52

19 years ago
Would it be possible to make it so that the UI doesn't show up if there's no plugin?

I'm also wondering if instead of a PGP menu item we need a Security or
Encryption menu item so that other things like S/MIME can be added later without
taking up all of the menu bar.
> I'm also wondering if instead of a PGP menu item we need a Security or
> Encryption menu item so that other things like S/MIME can be added later
> without taking up all of the menu bar.

I agree, that's what my post (see above) was about.

But IMO, we shouldn't hold the checkin for that. We can still tweak later, no
matter, if we check it in now or later. (At least I assume that. If there's
anything potentially preventing that - e.g. UI freeze or plugin interfaces -,
please say so. It doesn't seem to me, e.g. the plugin only seems to /be called/
and never /call back/.)

> My particular preference is to avoid gratuitous multiple |return|s, e.g., use
>  return (rc < 0) ? NS_ERROR_FAILURE : NS_OK;

I assume, you're talking about low memory and similar errors only? Anything less
standard, e.g. a missing PGP plugin, should return meaningful errors and also
hand it through up to the user. Compare bug 57057.
Keywords: helpwanted

Comment 54

19 years ago
I'd love to hide the UI when there is no plug-in. I just didn't know how to do 
that. If someone will let me know, I'll add it in.

I'd also like to be able to add some sort of indicator that lets the user know 
that an incoming message was encrypted. Currently, once the user's passphrase is 
entered, the message is decrypted automatically (but only to the display...the 
message store remains encrypted). Because NAI's PGP product allows passphrase 
caching, it's possible that the user won't even know that the message was 
encrypted. I didn't know how to add such an indicator to the UI.

Finally, I agree that the UI should be more general with regards to encryption 
and signing. The PGP menu I added was just to get started. Ideally, there should 
be some sort of Security menu, and any mail security plug-ins should be 
enumerated under it for encryption and signing.
> I didn't know how to add such an indicator to the UI.

We could just output some HTML code to the HTML for the msg body. Not perfect,
but I think, that's the way 4.x worked. E.g. just push an HTML table with an
icon to the output.

BTW: How do you mark signed msgs, then?

> any mail security plug-ins should be 
> enumerated under it for encryption and signing.

IMO, ideally, we should completely hide the encryption scheme in the normal UI
and just have "encrypt" and "sign" boxes. The rest (choosing OpenPGP or S/MIME)
should happen in the backgournd automatically. Details, see my post.

Comment 56

19 years ago
> We could just output some HTML code to the HTML for the msg body. Not perfect,
> but I think, that's the way 4.x worked. E.g. just push an HTML 
> table with an icon to the output.
>  
> BTW: How do you mark signed msgs, then?

Traditionally, we (NAI/PGP) have been inserting header and footer text into the 
message around the signed text. It looks something like this:

*** PGP Signature Status: good
*** Signer: Damon Gallaty <dgal@pgp.com>
*** Signed: 2/13/01 1:23:11 PM
*** Verified: 2/13/01 2:45:25 PM
*** BEGIN PGP VERIFIED MESSAGE ***

Test

*** END PGP VERIFIED MESSAGE ***
But what do you do if the original message contained lines like these?
Everyone can write mails containing the lines you mentioned, making the
recipient believe that the message was encrypted and/or signed.
Couldn't we add a little text panel conditionally the way we do for the
User-Agent header right now?

Comment 59

19 years ago
> But what do you do if the original message contained lines like these?
> Everyone can write mails containing the lines you mentioned, making the
> recipient believe that the message was encrypted and/or signed.

That's why it contains the following line:

*** Verified: 2/13/01 2:45:25 PM

so that the user can see that the message signature was verified at today's date 
and time. A spoofer would have to know the exact day and time that 
the message would be verified, or hope that the user doesn't notice 
that the date or time is wrong. Admittedly, it's not the most secure thing to 
do, but for many of NAI's PGP plug-ins, it was the only option, since we 
couldn't get access to the MUA's user interface to add some sort of status icon. 
I'm hoping we have better options with Mozilla.

> Couldn't we add a little text panel conditionally the way we do for 
> the User-Agent header right now?

That would be fine with me. It would be a lot better for indicating both 
encrypted and signed messages. What's the best way to do this?

Comment 60

19 years ago
To show signiature verification you could insert chrome objects/images into the 
message header [near the atachments icon] or the status area [near the psm lock 
icon].

as for only showing menu items if you're plugin is installed, that should be 
possible too.  The easiest way i can think of would be to add an oncreate 
handler for your chrome that tries to create an object that your plugin 
provides, if it fails, then you can set the menu items "hidden" attribute to 
"true".
OK, who is waiting on who in this bug?

Comment 62

19 years ago
I'm waiting on Scott to finish code review for the new files, at which point I 
will add them to the repository. I probably won't be adding the diff's until we 
sort out exactly how the UI is going to work. We still need to come up with some 
sort of scheme where encryption plug-ins are queried and added dynamically to 
the UI under a "Security" menu.

Comment 63

19 years ago
Alright, I've been through the new files and my only concern there is to make
sure that _new_ files use the MPL (as opposed to the NPL or some other license).
 Looking good.  Can you attach a patch that addresses my concerns from my review
of 2001-02-13 08:20?  After that and fixing license issues, I'll happily stamp
it with my sr=.

Comment 64

19 years ago
> We still need to come up with some 
> sort of scheme where encryption plug-ins are queried and added dynamically to 
> the UI under a "Security" menu.

Why not just overlay yourself into the menu?  All the cool kids (and wallet) are
doing it.

Because an overlaly is always shown, when it is installed. But in this case, the
Mozilla UI is always installed, just PGP plugin itself (e.g. the dll on Windows)
isn't always. Or so I understood.
The really cool thing about having menus and code is that you can tie the two
together, and have some code that sets state on the menus.

Of course, I really don't understand why you'd have the Mozilla UI for PGP
installed if the plugin wasn't -- why bother?  But that's OK -- I don't have to
understand.  I'm content to bet that anyone crafty enough to pull together a PGP
plugin can figure out how to hide/show an overlaid menu item as they deem
appropriate.

Comment 68

19 years ago
Looks good.  there are still a couple of old-style casts in there (near
|clazz|), but you addressed everything I cared about and more.  Assuming this
builds and you've done appropriate testing :-) ... sr=scc.  I can't wait to see
the PGP plugin that will take advantage of this work.

Comment 69

19 years ago
Just found out about this bug from Mozillazine! This is great because I have
been playing around with using PGP/GPG for web-based e-mail. I have got a crude
UI working which grabs text off Yahoo mail for encryption/decryption. I was just
going to use the inter-process communication code that I have submitted to
Mozilla (see bug 68702) to invoke command-line GPG to do the
encryption/decryption. Once this is working, it should be fairly easy to use it
with the mailnews UI being developed as part of this bug as well. Will post more
details soon.

Comment 70

19 years ago
Ok, I have super-review on the code. So, do I need to apply for CVS write 
access, or is someone else going to check the code in for me?
The best would be to ask Mozilla tean for a CVS access.
Damon, see http://www.mozilla.org/hacking/getting-cvs-write-access.html for
getting CVS Access.  I'll look around and try to find someone to check this in
for you in the mean time.  

scc, can you check this in?

Comment 73

19 years ago
asa - can you find a Mozilla QA person to write the test cases/outline for
testing this feature including integration into the current Mozilla UI?  Thanks.
Not to malign scc's super-review, but I still have some concerns about this
patch.  (I have to pull down the big tar and apply the changes to see the full
state here, so feel free to point out where I'm just being stupid.)

1: I don't fully understand why this isn't going into extensions/pgpmail or some
such place.  Are there actually changes to the content-handling capabilities
required?  (I would hope not, but if so, let's talk about them and figure out
how to fix them: people should be able to turn on PGP support without recompiling.)

2: ducarroz asked (good) questions about IDLifying the interfaces in question,
and the latest diff still shows them defined in C headers.  What's the issue here?

3: The code is fairly littered with naming inconsistencies ("mime" vs. "MIME" in
function names, for example), and we all know that those only get worse over
time.  Some of that is certainly due to the questionable example set by the
3.x-era MIME code, but there's a lot of room for improvement here.

4: modeline stuff is still bogus: tab-width: 2 isn't what we're looking for here
(8 is the Mozilla Way).

5: the use of piles of callbacks in the PGP plugin interface isn't very XPCOM. 
Why not either expect the PGP plugin to be an XPCOM component/plugin installed
through the usual manner, or, if that won't work, use a system like the
NSGetModule system to get a handle to an interface?

6: Unless I'm deeply mistaken, nsPGPModule::FindHeader is just searching through
the message to find a specific header.  Do we not have a utility function in
mailnews to do that?  (If not, we should!)

7: the file naming conventions are unclear to me (and I wouldn't know what to
put in PGPmoz.h if I were making changes), but we can probably make them more
consistent when we relocate this stuff to extensions/.

More later, after I get through the patched tarball, and not just the most
recent patch.
> 1: I don't fully understand why this isn't going into extensions/pgpmail or
> some such place.

You mean all of it?

> Are there actually changes to the content-handling capabilities
> required?  (I would hope not, but if so, let's talk about them and figure out
> how to fix them: people should be able to turn on PGP support without
> recompiling.)

You can't just plug in new content handlers, if you mean that. libmime doesn't
support that. PGP never supported 4.x. At least so I heard.
I do know that there are statements like |if (contenttype=="text/plain") handler
== libmimePlaintext| in libmime.

Yes, this is something definitely worth to be fixed. Might mean a libmime
rewrite, dunno. "We're accepting patches" *bg*

> 4: modeline stuff is still bogus: tab-width: 2 isn't what we're looking for
> here (8 is the Mozilla Way).

huh? I've seen 2 and 4, but hardly ever 8 as tab-width in Mozilla code. brendan
always says "Module owner sets rules".

> 5: the use of piles of callbacks in the PGP plugin interface isn't very XPCOM. 
Does the plugin itnerface actually use callbacks? I checked it, and if I didn't
overlook something, the DLL is only ever called and never calls Mozilla. (Or am
I missing something here?) Actually, this is what I like about it: The plugin
provided by NAI doesn't depend on the Mozilla implementation or any of its
interfaces. This gives more room for us to improve the code and interfaces
later. Which I expect to happen.

Comment 76

19 years ago
> 1: I don't fully understand why this isn't going into extensions/pgpmail or 
some
> such place.  Are there actually changes to the content-handling capabilities
> required?  (I would hope not, but if so, let's talk about them and figure out
> how to fix them: people should be able to turn on PGP support without 
recompiling.)
> 

In order to process incoming mail messages that contain PGP, the plug-in has to 
handle certain MIME content types. In the case of PGP, it has to handle 
text/plain, multipart/encrypted, and multipart/signed. Thus, it seemed like the 
best place to put a content type handler was mailnews/mime/cthandlers.

> 2: ducarroz asked (good) questions about IDLifying the interfaces in question,
> and the latest diff still shows them defined in C headers.  What's the issue 
here?
> 

I can't seem to find any comments here by ducarroz that ask about IDL-izing 
interfaces. The only comment I see is from scc about the fact that 
|nsIMimeContentTypeHandler| and |nsIMimeObjectClassAccess| are not IDL-ized, 
and those interfaces were written long ago by someone else. If you mean that I 
should IDL-ize nsIPGPModule, I can certainly do that.

> 3: The code is fairly littered with naming inconsistencies ("mime" vs. "MIME" 
in
> function names, for example), and we all know that those only get worse over
> time.  Some of that is certainly due to the questionable example set by the
> 3.x-era MIME code, but there's a lot of room for improvement here.
> 

Yes. Unfortunately, I didn't have anything else to go by, because I used the 
MIME code as a base for the plug-in code. Is there a guide to function and file 
naming standards somewhere? I have never been able to locate such a thing.

> 4: modeline stuff is still bogus: tab-width: 2 isn't what we're looking for 
here
> (8 is the Mozilla Way).
> 

I've been told to use either 2 or 4, and to convert tabs to spaces. What's the 
official standard, and where is this stated?

> 5: the use of piles of callbacks in the PGP plugin interface isn't very XPCOM. 
> Why not either expect the PGP plugin to be an XPCOM component/plugin installed
> through the usual manner, or, if that won't work, use a system like the
> NSGetModule system to get a handle to an interface?
> 

The problem is that the PGP plug-in itself (not the code checked into 
mozilla.org, but the module that contains the actual crypto) will come from 
third parties, such as Network Associates or Gnu Privacy Guard. In order to 
create an XPCOM component, we'll have to include mozilla code in our product. 
Does the MPL allow code to be included in another product without forcing the 
entire product to abide by the MPL?

> 6: Unless I'm deeply mistaken, nsPGPModule::FindHeader is just searching 
through
> the message to find a specific header.  Do we not have a utility function in
> mailnews to do that?  (If not, we should!)
> 

Agreed. I'll try to use the appropriate function if it exists.

> 7: the file naming conventions are unclear to me (and I wouldn't know what to
> put in PGPmoz.h if I were making changes), but we can probably make them more
> consistent when we relocate this stuff to extensions/.
> 

Again, I had little to go by as far as file naming conventions. I based it on 
what already existed in the MIME content type handlers, such as the vcard 
handler. PGPmoz.h is different, because this file comes directly from NAI's 
source code, though certainly I can rename it, or just include the necessary 
code in a different header file.

Comment 77

19 years ago
> You can't just plug in new content handlers, if you mean that. libmime doesn't
> support that. PGP never supported 4.x. At least so I heard.
> I do know that there are statements like |if (contenttype=="text/plain") 
handler
> == libmimePlaintext| in libmime.

Actually, it seems that you can just plug in new content type handlers. In 
mailnews/mime/src/mimei.cpp, line 316, a function called 
mime_locate_external_content_handler is called first before anything else. That 
function searches for a component who registered a contract id of the form 
"@mozilla.org/mimecth;1?type=xxx/yyy", where xxx/yyy is the content type. So, in 
the PGP code, I have the PGP module registered with the following contract ID's

"@mozilla.org/mimecth;1?type=text/plain"
"@mozilla.org/mimecth;1?type=multipart/signed"
"@mozilla.org/mimecth;1?type=multipart/encrypted"

Any incoming mail messages with these mime types will be handled by the PGP 
handler code. In the PGP handler code, if a PGP message is not found, it 
temporarily de-registers those contract IDs and creates a new mime object, so 
that the default handlers for those content types will be used instead.

Most of the code I wrote is basically a content type handler. The changes I made 
to existing mozilla.org code were to access MIME function through XPCOM, 
additions to the MsgSend code to be able to send PGP encrypted and signed 
messages, and additions to the XUL file for the mailnews UI.

Initially, I just want to check in the new files for the PGP content-type 
handler. There's still discussion on how to best integrate PGP and other mail 
encryption plug-ins into mailnews, so I don't think that code should be checked 
in just yet.

Comment 78

19 years ago
Some more comments on IDLification. Would it be possible to IDLify
nsIPGPModule.h while making everything scriptable? This would mean serializing
void* variables like msg_body and msg_header to make them strings (char*). I
now have command-line GPG working with Mozilla (using the inter-process
communication component described in bug 68702), and I would expect
command-line PGP to work as well. I can supply a platform-independent
Javascript implementation of nsIPGPModule right away, if all the methods are
made scriptable. Otherwise, I will need to compile platform-dependent
implementations to handle the void* stuff, which is always messy!
(I crashed when editing this the first time, so you get a much shorter version.)

XPCOM and MPL: MPL doesn't taint across file boundaries, which is how
Netscape/AOL gets away with using XPCOM and other code in their AIM plugin,
without coughing up the whole component in source.  NB: if you're contributing
your code under the MPL, it behooves you greatly to study the license, because
licensing surprises are very unpleasant.

MIME vs mime in function names: there are no hard-and-fast rules, but
consistency is king.  Pick a capitalization (and a prefix; the COM_* stuff is a
bit weird, and I don't understand the pattern) and use it universally.

tab-width: doesn't really matter, given indent-tabs-mode: nil (c-basic-offset
controls indentation), and my reasons for preferring 8 there are apparently
unique to me.  Sorry for the noise.

IDLification: you're quite right: it was scc who pointed out that
nsIMime{ContentTypeHandler,ObjectClassAccess} weren't IDLized.  You don't have
to do that, but please do use IDL for your new interfaces (nsIPGPService and
whatever you use to interface with the plugin).

source tree location: I _really_ think this should go into extensions/pgpmail or
some such, because people shouldn't have to rebuild their Mozilla to add this
in.  (You'll thank me later, when you can package up a nice .xpi for Netscape
6.5 or whatever.)
sorry for jumping in so late here.  I've been off on the mailnews performance
branch and been slow to handle trunk issues.

first, it's very cool that you are doing this work for mozilla.  you rock!

second, I'm in complete agreement with shaver's suggestions:

1) almost all of the code should be under extensions, except for the changes to
the mailnews code to provide the necessary hooks.

2) the UI should be done using overlays.  again, we might need to change the
mailnews UI to work with the overlays (common tricks:  adding boxes or proving
ids to existing elements to hang overlays off of, etc), but the ui should also
live under the extensions directory.

3) packaging it all up as a .xpi file, not part of the mailnews download.

4) fixing the build system to build it as extension.

the philosophy is users who don't use PGP should pay as small of price as
possible for this feature.  

can you provide a new, update and complete patch for me (and mscott) to review?

Comment 81

19 years ago
> Any incoming mail messages with these mime types will be handled by the PGP 
> handler code. In the PGP handler code, if a PGP message is not found, it 
> temporarily de-registers those contract IDs and creates a new mime object, so 
> that the default handlers for those content types will be used instead.

This sounds functional, but is there no cleaner way to do it?  The ideal
solution seems to be returning some sort of "I don't want to handle this
content" response; if the current interface doesn't allow for this, maybe it
should be changed to?  Another possibility (not nearly as good) would be to save
the handler information before registering and calling the old handler directly,
as is common in library jump-point interceptions.  (But this is kind of ugly,
and perhaps worse than the de-registering solution.)

I don't have the answer here, I'm just thinking that there ought to be a better
way than de-registering the handler -- this sort of conditional override may be
a common extension, and a better-generalized solution may be warranted...

Comment 82

19 years ago
> tab-width: doesn't really matter, given indent-tabs-mode: nil (c-basic-offset
> controls indentation), and my reasons for preferring 8 there are apparently
> unique to me.  Sorry for the noise.

If we're talking about how many spaces a hard tab should represent on the
screen, I'll agree that it must always be 8.  (So it's not unique to you.)  I've
seen some ugly situations caused by mixed tabs and spaces where hard tabs were
set to display at a size OTHER than 8 spaces, and it's not worth the nightmare.

Now, when it comes to soft tabs and indentation levels, I think that should be
left to developer preference, as long as there's consistency at least within the
same file or module, if not across the entire application.  As long as any hard
tabs in the file can be expanded to spaces at a tab-width of 8 without changing
the appearance of the tabs on the screen, I'm happy with it...

Comment 83

19 years ago
> This sounds functional, but is there no cleaner way to do it?  The ideal
> solution seems to be returning some sort of "I don't want to handle this
> content" response; if the current interface doesn't allow for this, maybe it
> should be changed to?  Another possibility (not nearly as good) would be to 
save
> the handler information before registering and calling the old handler 
directly,
> as is common in library jump-point interceptions.  (But this is kind of ugly,
> and perhaps worse than the de-registering solution.)

The big problem is that libmime assumes that there is only one handler for every 
content type, so there is no mechanism for a handler to say "I don't want to 
handle this...let the next handler do it". I am loathe to alter libmime without 
good reason and guidance, as that code has been around for a while without 
change.
Well, I think that should be changed. I don't think the PGP plugin is the only
one additionally being interested in "text/plain". Look at the files' blame to
see who you could consult on changing the code and how best to go about it.

I suggest a new bug be filed for that though, and then either we make this bug
depend on that (and don't land before that is fixed so this can be fixed), or
land this now and have the other bug to ensure we fix this.

Comment 85

19 years ago
I can understand the reluctance to modify libmime, but this seems like something
that people will have to workaround again and again if it isn't fixed to do the
Right Thing.  I like the idea of making a new bug for it, making this one
dependent on it, and finding the best person to add the new functionality. 
While it's arguably an "enhancement", it would probably be pretty
straightforward code -- instead of one handler, you make a prioritized queue...
This is general architecture work in libmime. This is nothing NAI should be
forced to do or which should stop the checkin of this code. General architecture
is IMO the resposibility of the owner of the module, not an occasional hacker.
(If the latter wants to and can do it, all the better, but he shouldn't be
forced to do that.)
It's not like this code were a mess or similar...
Which is why I suggested a new bug be filed. I don't care who goes about fixing
that bug, but I do think we shouldn't be introducing ugly hacks into the code
without at least a bug on removing it ASAP or on fixing this beforehand so the
ugly hacks aren't needed.

From what Damon's been saying it sounds like he can pretty much contain the ugly
hacks to the PGP code, so he could just use that (yes, as in check it in) until
libmime has been fixed to more elegantly deal with this.

On the other hand, it also sounds like we're not in a hurry to get PGP in (since
there still are some outstanding issues), so why not take the time to do this
the right way? File that bug (if it doesn't exist yet), get someone to fix it,
then rewrite the relevant parts of this code to make use of that.

In the mean time, would it be a good idea to at least get the new files checked
in ASAP ("NOT PART OF BUILD", on a branch perhaps) so people can more easily
play with it and keep it from bit-rotting?

Updated

18 years ago
Blocks: 73075
I'd hate to see this work bit rot.

I'd be willing to help with the ui issues, and ducarroz seems like he is helping 
with the back end issues.

I agree with jag, let's get the new files that can get checked in, checked in.

the everyone involved can work with patches.

I've got the latest tar ball of new files.  are we settled on a place in the 
mozilla tree for it?  (mozilla/extensions/pgpmail?)
dgal@pgp.com: let's see if we can sort this out :-) Could you possibly give us 
the latest version of your PGP integration work, preferably as one big diff -u 
from the root directory of your Mozilla tree? 

I particularly want the UI file diffs (.xul, .js) because they will need an 
overhaul due to certain changes to the XUL syntax and, from comments, it seems 
that there's some UI integration work to do here.

Also, did anything ever happen to the idea to have a test ROT-13 plugin? Or is 
that already part of it?

Gerv
cvs diff -uN if the patch includes new (cvs added but not committed) files.

Let's get this in for 0.9, if possible.

/be

Comment 93

18 years ago
None of the new files that I've created have been "cvs add"ed, because I don't 
have cvs access yet, so I'll only be posting a diff -u. The uncomitted files are 
in the tarball attached on 3/7/01.
on my linux box, I've got the new files (from the last .tar.gz file) staged in
mozilla/extensions/pgpmail, where I think it belongs.

1) the first step would be getting the new files in the tree.  (once we agree on
where, I can handle that.)
2) second step, provide a patch that along with the new files gets the ROT-13
sample working.  (from previous comments, it sounds like we don't have access to
the PGP plugin from damon to test with.)

then we can work on getting the MIME / UI issues with the patch sorted out.

can we agree on mozilla/extension/pgpmail, so that I can start step 1?

damon, if the last tar ball of new files isn't the lastest, please attach a new one.
cvs adding a file does nothing to the repository.  I don't believe you need CVS
commit access to cvs add a file (directories are different -- cvs add subdir
does add the directory immediately, no commit needed).

/be
Er... just tried this with the mozilla tree:

content% cvs add viewsource.css 
cvs [server aborted]: "add" requires write access to the repository

Comment 98

18 years ago
Damon, maybe you should use nsresult as return value in your new API's
parameters instead of PRBools? 
I'm going to get the ball rolling by adding the new files to the tree under
mozilla/extensions/pgpmail

then, interested parties can work with patches and we can address issues with
the new files and the changes required.

I'll report back when that is done.
the lasest patch will not work against the trunk.

before I add the files, I'll get it working again and then attach the patch.
still working on this.

I got things building, and I've got files (including .xul,.js,and .dtd) under
mozilla/extensions/pgpmail

I'm not able to send mail yet, I get an error on send when I try to "encrypt"
the email.

the more I play around with the code, the more I *don't* think it is ready for
the tree.  it's a good start.

I think the appropriate thing is for ducarroz, damon and me to work things out.

I'll see how far I can get on my own, and then attach a new patch for people to
play with.
ok, I got the sample (rot-13) plugin working, and I can send mail with it.

I've done what brendan and shaver suggested:  cvs add the files (but don't
commit), so that I can generate a diff that includes the new files.

I'll attach what I've got, and then explain what we should work on next.
A couple of observations:

The patch mixes MPL and NPL headers. Damon - did you say you were happy for all 
the new code to go in under the MPL?

The front-end stuff looks good to me (for what that's worth, which isn't much) 
but are we going to name everything in it PGP_ or try and create something a bit 
more general (either for both PGP and GPG, or for any pluggable encryption 
module) like an "Encryption" menu where modules can plug in their names?

Gerv
here's some issues.  this not complete.

1)  your NS_PGP_*_CONTENT_TYPE_HANDLER_CID look like you created on, and then
created the other 2 by incrementing.  you need to create 3 real uuids

2) nsIMimeObjectClassAccess.h and mimecom.cpp:

you've got a bunch of methods [like MimePartBufferCreate()] declared with
NS_IMETHOD, and then in mimecom.h & mimecom.cpp, you have an extern "C" helper
fuctions that return "void *", "void", and int.  they should return "PRUint32"

3) displayPGPOptions() and displayPGPAbout() should not be methods on the
nsIMsgCompFields.idl interface.  you started to implement them in pgpOverlay.js
and that is where they belong.

4) the sample plugin gets built and installed into the components directory,
which is the wrong place.  (not sure where it belongs yet)

these are the small, easy issues.  there are much bigger issues, specifically
how to plug into mime and compose, which will require more thought.

damon, can you review the changes I made, test this patch on win32, and then
address those issues?

then, we can discuss the bigger issues.

after apply that patch, you need to do "./configure --with-extensions=pgpmail"


gerv:  the front end stuff is not good.  

we've tweaked the compose xul to include the pgp overlay.  that can't be checked
in, or compose will break when pgpmail isn't built.

we need to fix the front end stuff to do overlays the right way.

Comment 109

18 years ago
gervase.markham@univ.ox.ac.uk wrote:

> The patch mixes MPL and NPL headers. Damon - did you say you were 
> happy for all the new code to go in under the MPL?

The new files that I provided in the 3/7/01 attachment should all have the MPL. 
If not, let me know, as my intention was for all of it to go under the MPL.

The diff's are against files that already exist in the tree, and I am not the 
owner, so I can't really change those licenses.

Comment 110

18 years ago
sspitzer@netscape.com wrote:

> 1)  your NS_PGP_*_CONTENT_TYPE_HANDLER_CID look like you created 
> on, and then created the other 2 by incrementing.  you need to
> create 3 real uuids

Is there an approved uuid generator I should be using? I was using "guidgen", 
which is provided with Microsoft's Visual C++ for Windows. When I asked for an 
identifier three times from guidgen, it gave me those three IDs, each one 
incremented from the one before.
1) if you used guidgen, then I'm wrong.  I'm so used to the uuid mozbot
generates that those looked fake.

2) I messed up the license in a few of the makefiles.  I've fixed all the files
in mozilla/extensions/pgpmail to use the MPL

I'll attach a corrected version.

Comment 112

18 years ago
I wrote:

> gervase.markham@univ.ox.ac.uk wrote:

>> The patch mixes MPL and NPL headers. Damon - did you say you were 
>> happy for all the new code to go in under the MPL?

> The new files that I provided in the 3/7/01 attachment should all have
> the MPL. If not, let me know, as my intention was for all of it to go 
> under the MPL.

> The diff's are against files that already exist in the tree, and I am 
> not the owner, so I can't really change those licenses.

Oops...just realized you were talking about sspitzer's patch, not mine. Sorry 
about that.

Comment 115

18 years ago
I have attached a JS component implementing the nsIPGPModule interface, except
for the FindHeaders method. That method is not PGP-specific and probably belongs
elsewhere. it also violates XPCOM conventions, by returning pointers to the
input string. I temporarily moved it to nsMsgSend.cpp to get things working.

The attached component actually works with Mozilla 0.8.1; I managed to send a
GPG encrypted message using dgal's patches, but deleting the supplied
implementation of nsIPGPModule. The JS component uses the IPCService module
(which is part of protozilla, http://protozilla.mozdev.org) to execute command
line GPG as needed. It should also work with command line PGP with minor tweaks.
(The IPCService module works on Unix and Windows platforms. Therefore this JS
component should work on those platforms as well.

An RFE to incorporate the IPCService module as a mozilla extension has been
filed (see bug 68702).

Comment 116

18 years ago
Sorry it's taken me so long to respond. I've been tied up with other development 
projects.

sspitzer@netscape.com writes:

> 2) nsIMimeObjectClassAccess.h and mimecom.cpp:
> 
> you've got a bunch of methods [like MimePartBufferCreate()] declared with
> NS_IMETHOD, and then in mimecom.h & mimecom.cpp, you have an 
> extern "C" helper
> fuctions that return "void *", "void", and int.  they should 
> return "PRUint32"

The helper functions in mimecom.h and mimecom.cpp are wrapped inside the calls 
in nsMimeObjectClassAccess.cpp, which do return an "nsresult" type. Check out 
nsMimeObjectClassAccess.cpp to see what I mean. Note that some of the functions 
like MimeObjectWrite and GetmimeInlineTextClass were already there from a long 
time ago. I was basically following the pattern already established.

> 4) the sample plugin gets built and installed into the components 
> directory,
> which is the wrong place.  (not sure where it belongs yet)

Is there a proper directory where add-ons should be installed? I imagine it 
wouldn't be "plugins", since this isn't a plug-in as defined by the plug-in API.
sorry for the delays.  

as you can tell from the delays, this isn't the top priority for the mailnews
project (speaking as one of the module owners for mailnews) so it tends to get
starved.

I think the proper next step is to come up with the proper, extensible [XPCOM]
architecture for MIME / compose plugins.  (this includes having support for
dynamic UI.  it's not as much work as the back end part, I'm just mentioned it
for completeness.)

the people we need in that discussions would be damon, gervace, ducarroz,
mscott, bob lord (or someone who knows about S/MIME), and anyone else who is
interested.  once it's designed and implemented in mozilla, we can leave the
implementations for PGP, S/MIME and rot-13 to the interested parties.

I'd suggest meeting in IRC [#mozilla on irc.mozilla.org:6667] sometime after the
0.9 or 0.9.1 milestone.  By then, we can independently come up with some ideas
of what we need.

comments?

Comment 119

18 years ago
not jglick or robinf? and perhaps #mozmail
#mozmail would make more sense.

yes, I forgot about some UI people but they are welcome to join in.   

most of the initial discussion should focus on making the back end code
extensible, not the UI.

while the design of the UI is non-trivial, the implementation is a simpler
issue, and we've got an architecture for that already [overlays].

Comment 121

18 years ago
That sounds like a good idea. Just keep me informed when to meet on IRC.
Mandatory flame:

> this isn't the top priority for the mailnews project (speaking as one of the
> module owners for mailnews)

Speaking as contributor to Mailnews, distributor and user, I think you are
wrong. 81 votes clearly shows that PGP should be a top priority. If module
owners have a different opinion, then they are already overruled.

Apart from that, incorporating *any* good patches should be a top priority. The
project won't make progress, if module owners are so busy with their own coding
that they cannot help others with incorporating patches.

I'm pretty sure that Netscape management shares my opinion at least in the last
paragraph. (Not that it would matter much.)

> the people we need in that discussions would be damon, gervace, ducarroz,
> mscott, bob lord

Can you arrange it so that the patch can be checked it for mozilla 0.9.1,
assuming that Damon is reasonably fast with making the necessary code changes?
This patch is waiting for almost 3 months already.

</flame> (Sorry that it's almost always me who does this.)

Comment 123

18 years ago
ben.bucksch@beonex.com writes:

> Can you arrange it so that the patch can be checked it for mozilla 0.9.1,
> assuming that Damon is reasonably fast with making the necessary 
> code changes?
> This patch is waiting for almost 3 months already.

What are the "necessary code changes"? I submitted a patch on 04/12/01 that 
should address the issues listed in Seth Spitzer's comments on 04/04/01. Are 
there any others I should address that would hold up a check in?
Damon, I guess, sspitzer sees some general problems (from his POV) and wants you
to meet with the above mentioned people to work out what exactly to do (that's
what I meant with "necessary code changes").
>> this isn't the top priority for the mailnews project (speaking as one of the
>> module owners for mailnews)
>
> Speaking as contributor to Mailnews, distributor and user, I think you are
> wrong. 81 votes clearly shows that PGP should be a top priority. 

I should have said "not a top priority for us right now".  We've got crashers to
fix, data loss bugs to fix, performance bugs to fix, basic functionality
correctness bugs to fix.  You think PGP is more important than those?

> If module
> owners have a different opinion, then they are already overruled.

We can easily be overruled.  All you have to do is contribute more code that we
do, and know the code better than we do.  Until then, you'll have to be
understanding.

> Apart from that, incorporating *any* good patches should be a top priority. 
> The project won't make progress, if module owners are so busy with their own 
> coding that they cannot help others with incorporating patches.

yes, incorporating good patches is a priority.  But "good" is subjective.

> Can you arrange it so that the patch can be checked it for mozilla 0.9.1,
> assuming that Damon is reasonably fast with making the necessary code changes?
> This patch is waiting for almost 3 months already.

The patch is not ready.  we need to figure out how to properly plug into mime
and compose.  that's what's holding up this patch.

damon, gemal, benb (and others)

a few of us from the mailnews team spent our lunch hour last week talking about 
how to extend the architecture to allow PGP support.

here are the notes:  
http://www.mozilla.org/mailnews/compose_send_plugin_arch_notes.html

some changes are required to the UI and mime, but most of the work will pushed 
onto the plugin authors, who will have to write the necessary libmime content 
type handlers and the necessary stream converters.

I'm new to those areas, so as I learn more about content type handlers and 
stream converters, I'll be updating and correcting the notes.  

the notes are a little cryptic, so send me mail if you have questions and I'll 
update them.

this gets up one step closer to a discussion in #mozmail. 

Comment 127

18 years ago
Since it seems like there are lots of stuff to do, can we make this a tracking
bug and split off isues to smaller bugs?

For example, we can spin off a bug about the UI and then get jglick, robinf, mpt
and other people to do a spec...

Comment 128

18 years ago
Does it matter that RFC 2822 has replaced RFC 822?  (Here or in other mailnews
bugs, I don't know...)
I'll mail the people who are supposed to meet to make an appointment. Mail me,
if you are interested, so you can influence the date. I'll announce the date
here, if/when we reached consensus.

Damon, it seems clear already that the plugin should use "overlays". There might
be some doc in it. Mailnews itself is a good example for overlays (see the
*Overlay.* files in mailnews/ and where they are hooked up in xpfe/communicator,
xpfe/components etc.). If you have problems, lots of people who worked with XUL
are probably willing to help you (try #mozilla, #mozillazine for simple stuff or
the newsgroups for harder questions).
I've updated http://www.mozilla.org/mailnews/compose_send_plugin_arch_notes.html 
with feedback I've received about encrypting unsent messages, and an open issue 
on what if the converter needs to block the UI.

Comment 131

18 years ago
I've already started using overlays, although right now it's very PGP-specific. 
If you'll look at some of the patches attached to this bug, one file you'll see 
is "pgpOverlay.xul", with the corresponding "pgpOverlay.js" and 
"pgpOverlay.dtd". We just need to figure out how to transform this into a 
generic encryption plug-in interface.
here's the chat log from #mozmail

http://www.mozilla.org/mailnews/mozmail-5-23-log.html

current state:

1) damon to work on using overlays in the compose UI.
2) benb / damon will give me some architecture notes to post on mozilla.org
for evaluation.
3) I'll respond to ben's questions about the document I posted 
(http://www.mozilla.org/mailnews/compose_send_plugin_arch_notes.html) and 
clarify that document.
futuring.

I've got support from staff@mozilla.org on this, but I'd like to explain the
decision to Damon and others.

the module owners for the mailnews front end (sspitzer), back end (mscott),
compose and MIME (ducarroz) don't have time to help design and implement the
architecture changes needed to support PGP / S/MIME right now.

we did briefly discuss where we'd start if we did have time.  see my rough notes
http://www.mozilla.org/mailnews/compose_send_plugin_arch_notes.html

I currently don't even have time to finish the notes, respond to questions I've
received about the notes, or to research to see if the design we sketched out is
sound.

We're all very focused on 0.9.1 and 0.9.2 bugs.

Given the current mailnews bugs, and our current priorties, this is just going
to have stay in limbo.

Eventually, mozilla mailnews will have S/MIME & PGP support.  I can't give you
on ETA on when.  Unless priorities drastically change, this will not happen
before Mozilla 1.0, that is why I'm futuring instead of setting target milestone
to Mozilla 1.0

I'm sure this is frustrating to some of you, especially to those who have
written code and submitted patches.  I apologize that this decision wasn't made
earlier. 

If our priorities change, I'll update this bug.

Target Milestone: --- → Future

Comment 134

18 years ago
I'd like to express my personal opinion on the matter. Context: I'm not a 
Mozilla developer, but I'm well-versed in relevant security issues and I've been 
following this bug with interest.

In terms of security, e-mail is currently one of the weakest facilities on the 
Internet. HTTP/SSL, SSH and SCP provide encrypted and authenticated protocols 
for the respective needs, but e-mail by and large still relies on plaintext 
messages passed in the clear by POP3 and SMTP. The implications are obvious and 
frequently experienced. This is paradoxical, considering the vast popularity of 
e-mail and its frequent use for sensitive information.

This grave situation persists mainly because of lack of functionality in common 
e-mail software. Encrypted e-mail ought to become the *default* format, and it 
must become trivial to import public keys, to send standard-compliant signed and 
encrypted messages, and verify their validity upon receipt. None of this is 
possible without e-mail software support. And Mozilla is in the position to 
change this situation.

It is my opinion that in this case, clean architecture should be sacrified for 
functionality. Yes, providing this functionality in Mozilla 1.0 (i.e., anytime 
soon) may necessitate unmodular, specialized and hard-to-maintain changes in the 
codebase. It is not possible to do the Right Thing with the given resources and 
timeframe. Then go ahead and just do a Working Thing and fix it later, because 
this one is too important.

Mozilla.org is spending an inordinate amount of time on building a fantastic 
infrastructure, to-the-letter compliance with numerous standards and 
owe-inspriring customizability. But as a practical web user, site administrator, 
programmer and consultant, I'd rather give up all of these than have my e-mails 
show up in the wrong hands. 

Hence, I urge you to reconsider your decision.
FYI: In the IRC meeting, I thought we agreed on a compromisse: that Damon
changes the patch so that its impact on a Mozilla without PGP support is minimal
(mostly one method call in Mailnews Composer backend) without actually making
drastic changes to the infrastructure (which is, IMO, unrealistic to require an
occasional contributor to make). That patch could then go in and be improved
when there is time, but in the meantime, it could at least be used.
Note that e.g. the Netscape spell checking component leaves similar or even more
traces in Mozilla, and nobody called for a generic architecture in that case
either. 

Comment 136

18 years ago
When Netscape 6 needed a spellchecker didn't you wasn't the implementation
rather cludgy and inflexible.  Then is now being rewritten to support a generic
API.  Shouldn't this be the direction to take for PGP/SMIME as well?

Comment 137

18 years ago
I strongly agree with mozilla2eran@tromer.org's remarks here.  Email encryption
functionality is of great social importance, and as such it REALLY belongs in
Mozilla 1.0, even if it isn't ideally architected.  The current security of the
vast majority of email is in a truly shameful state, and Mozilla could be in a
position to help.  Having decided that Mozilla should contain a mail client, it
should be equally important to support this goal.  (Don't the 96 votes on this
bug MEAN anything?)

Especially since there's a working patch, this really should be integrated into
the CVS tree ASAP, not thrown on a back burner for not being perfect.  Make it
perfect after 1.0 when you have the time.  Until then, MAKE IT AVAILABLE so that
the entire world can benefit from more secure email.  (And ideally distribute it
with a working GPG plugin, or at least make such a plugin trivial for the user
to setup if export restrictions are a problem.)

Legal documents, medical records and other sensitive and confidential is being
sent through email because it works and it's convenient, and people need to get
the job done.  Most of it isn't encrypted, and we should ALL be worried about
this sort of thing.  Maybe your doctor will send YOUR medical records through
unencrypted Internet email tomorrow.  Who wants to take that risk?  Once
confidential information has been compromised, you can't fix it later.  You
can't close Pandora's Box again.

On a different note, it also belongs in Mozilla 1.0 for the simple reason that
secure email is in high demand, and providing it in the stock distribution would
provide a strong incentive for people to switch to Mozilla.  And then, like
Microsoft, Mozilla could benefit from network effects for once -- Mozilla users
would send encrypted email to their friends, who would use Mozilla and send
encrypted email to THEIR friends, etc.  Microsoft has a shoddy history when it
comes to security; Mozilla could carry this banner -- it would be VERY useful on
a purely practical basis, to aid Mozilla's market penetration...

Comment 138

18 years ago
Deven - interesting that you should mention Microsoft having
a shoddy record.

I recently came across the following press clipping:

REPORT URGES MORE ENCRYPTION
Echelon, the U.S.-based spy system whose existence has been long
rumored but never substantiated, does indeed exist and poses a
serious privacy threat, according to a newly released, 108-page
report from the European Parliament. The report is based
upon interviews with experts in the fields of security and
communications, who have provided testimony that the United
Kingdom, Australia, Canada, and New Zealand are helping the
United States manage the communications-interception system.
The report claims that Echelon intercepts "a very small portion"
of corporate and civilian communications across the globe, but
could come up with no proof that the system is sharing these
communications with U.S. companies. The report suggests that
computer users protect their e-mail communications from Echelon
by using encryption.
(Associated Press, 29 May 2001)


Being interested in such things, I tracked down the relevant
report from the European Union website:
    http://www.europarl.eu.int/stoa/publi/pdf/98-14-01-2en_en.pdf


Hiding in the technical annexe at the end were some rather
facinating allegations:



39. From the 1940s to date, NSA has undermined the effectiveness
    of cryptographic systems made or used in Europe. The most
    important target of NSA activity was a prominent Swiss
    manufacturing company, Crypto AG.

    Crypto AG established a strong position as a supplier of code
    and cypher systems after the second world war. Many governments
    would not trust products offered for sale by major powers. In
    contrast, Swiss companies in this sector benefited from Switzerland's
    neutrality and image of integrity.

40. NSA arranged to rig encryption systems sold by Crypto AG, enabling
    UKUSA agencies to read the coded diplomatic and military traffic of
    more than 130 countries. NSA's covert intervention was arranged
    through the company's owner and founder Boris Hagelin, and involved
    periodic visits to Switzerland by US "consultants" working for NSA.

    One was Nora L MacKabee, a career NSA employee. A US newspaper
    obtained copies of confidential Crypto AG documents recording
    Ms Mackebee's attendance at discussion meetings in 1975 to design
    a new Crypto AG machine".

41. The purpose of NSA's interventions were to ensure that while its
    coding systems should appear secure to other cryptologists, it was
    not secure. Each time a machine was used, its users would select a
    long numerical key, changed periodically. Naturally users wished to
    selected their own keys, unknown to NSA. If Crypto AG's machines
    were to appear strong to outside testers, then its coding system
    should work, and actually be strong.

    NSA?s solution to this apparent condundrum was to design the machine
    so that it broadcast the key it was using to listeners. To prevent
    other listeners recognising what was happening, the key too had also
    to be sent in code - a different code, known only to NSA. Thus, every
    time NSA or GCHQ intercepted a message sent using these machines, they
    would first read their own coded part of the message, called the
    "hilfsinformationen" (help information field) and extract the key
    the target was using. They could then read the message itself as
    fast or even faster than the intended recipient

42. The same technique was re-used in 1995, when NSA became concerned
    about cryptographic security systems being built into Internet and
    E-mail software by Microsoft, Netscape and Lotus. The companies
    agreed to adapt their software to reduce the level of security
    provided to users outside the United States. In the case of Lotus Notes,
    which includes a secure e-mail system, the built-in cryptographic system
    uses a 64 bit encryption key. This provides a medium level of security,
    which might at present only be broken by NSA in months or years.

43. Lotus built in an NSA "help information" trapdoor to its Notes system,
    as the Swedish government discovered to its embarrassment in 1997. By
    then, the system was in daily use for confidential mail by Swedish MPs,
    15,000 tax agency staff and 400,000 to 500,000 citizens. Lotus Notes
    incorporates a "workfactor reduction field" (WRF) into all e-mails sent
    by non US users of the system. Like its predecessor the Crypto AG
    "help information field" this device reduces NSA's difficulty in
    reading European and other e-mail from an almost intractable problem
    to a few seconds work. The WRF broadcasts 24 of the 64 bits of the key
    used for each communication. The WRF is encoded, using a "public key"
    system which can only be read by NSA. Lotus, a subsidiary of IBM,
    admits this. The company told Svenska Dagbladet:
      "The difference between the American Notes version and the export
       version lies in degrees of encryption. We deliver 64 bit keys to
       all customers, but 24 bits of those in the version that we deliver
       outside of the United States are deposited with the American government".

44. Similar arrangements are built into all export versions of the web
    "browsers" manufactured by Microsoft and Netscape. Each uses a standard
    128 bit key. In the export version, this key is not reduced in length.
    Instead, 88 bits of the key are broadcast with each message; 40 bits
    remain secret. It follows that almost every computer in Europe has, as
    a built-in standard feature, an NSA workfactor reduction system to
    enable NSA (alone) to break the user's code and read secure messages.


Hmm, I wonder if the EU would consider helping fund some developers to
work on this bug?
> Hiding in the technical annexe at the end were some rather
> facinating allegations:

Old news. Please be aware that approximately 147 people get emailed when you 
comment on this bug.

> Hmm, I wonder if the EU would consider helping fund some developers to
> work on this bug?

A more serious suggestion might be an approach to the newly-formed OpenPGP 
Alliance (http://www.openpgp.org), who could distribute the request to their 
members. This request would have to go through staff@mozilla.org. I have final 
exams right now - if no-one has got the ball rolling by composing a letter to 
staff@ in the next two weeks, I will. But, given that 147 people are getting 
this message, someone should be able to manage that. :-)

Gerv
> Hmm, I wonder if the EU would consider helping fund some developers to
> work on this bug?

Already happened so-to-say. 2 years ago, the BMWi, the German Department of
Commerce, funded the GnuPG project with 10.000$ for coding UI-support for
Netscape Messenger (4.x or Mozilla), IIRC. The only result from this, that I
know of, is mentioned in bug 56052.
Hi.  I'm Mike, and I'll be your staff@mozilla.org representative this evening. 
I want to just write "seth is right, please let him do his job" and be done with
it, but I know I'll not get off that easily.

But Seth is right: this patch isn't ready for our tree, and it's not going to be
until we have a better architecture for plugging these things in.  That he
doesn't have time right now, as we're a small number of milestones from 1.0 with
a frightening amount of work remaining, to design and specify an architecture
for these plugins isn't very surprising, and it's _certainly_ not a dereliction
of his module-owner duty.  If someone wants to put together a design proposal
for composer-and-so-forth plugins, I'm sure we can find eyes to review a
completed draft, but nobody has stepped up to do that yet.  (Which is a little
amazing, isn't it, given that this bug is so important to the entire world?)

We already have too much code in the tree that was supposed to be fixed later,
and wasn't, and -- without any malice or insult intended -- I think mailnews
already has all the legacy code it can handle.  I didn't follow the spellchecker
checkin, but the details don't matter: if we bow to such things as precedent,
we'll end up with a tree full of wallet.  (If the things I read in this bug are
true, then the spellchecker stuff might have been a spot of poor ownership, but
that's not relevant to this bug, and I don't want to hear further discussion of
it here.)

It is, indeed, unlikely that an occasional contributor to Mozilla will be able
to single-handedly design and implement the sort of architecture that Seth has
requested, but that's not a reason to lower our standards.  There are lots of
people on this bug with mailnews and/or general Mozilla experience that can help
out, if they choose to, or we can wait until Seth has enough time to hold
someone's hand himself.

It is not quite, and Ben alleges, a module owner's primary responsibility to
incorporate patches into the tree.  It's the module owner's primary (perhaps
only?) responsibility to defend and enhance the quality of his or her module. 
Sometimes that happens by taking patches, and sometimes it happens by rejecting
them (during the review cycle, for example).

But wait, there's more.  Unless I'm really misreading the code and comments,
this patch doesn't do what you think it does (though svn's might).  It doesn't
actually let you send a PGP encrypted message, or decrypt/verify an encrypted
message you recieve.  Why not?  Because the only thing that this patch works
with is NAI's closed-source, as-yet-unavailable PGP plugin.  Try it: apply the
patch to your tree, and send a PGP-encrypted message to yourself.

(This is not a condemnation of Damon's work, by any means: Mozilla has always
been eager to take good infrastructure patches that provide general extension
mechanisms, even where the primary motivation for said architecture is to
support a closed-source module.  Java and OJI are a half-good example, and the
plugin API is another half-good one.)

I _believe_ that all of svn's stuff could be made xpinstallable (including the
pieces from IPCModule), so perhaps some of this energy should be channeled into
making such a package available?

To sum up, then:

 * Seth's ownership of the mailnews code, and of this bug in particular, isn't
   at all lacking.  In fact, it has generally been exemplary, and 
   staff@mozilla.org have begun a cloning project to try to find more
   owners like Seth.
 * This patch isn't ready to go in, though I don't think that it would really
   sate the masses gathered here even if it _did_ go in. (Please, let me know if
   I'm wrong and you can really do PGP things with this patch installed, but
   note that it doesn't really change the crux of the issue here.)  Until it 
   _is_ ready -- and Seth makes that determination, with the full support of
   staff@mozilla.org -- it should not go in.  If it doesn't fit, you 
   must...wait.
 * It is, indeed, sad that 97 people will be disappointed in Mozilla 1.0 because
   of its lack of PGP support, but it's sadder that at best five of those 97
   have decided to light a candle, the rest preferring to curse our PGP
   darkness.  Kudos to Damon for taking us this far, and shame on the majority
   of the rest of us (myself included, I suppose!) for not following his lead.

Please, when commenting on this bug, bear in mind that your comments are going
to be read by about 150 people.  Be concise, and try to avoid simply repeating
points you or others have made before, in hopes that people will Finally Understand.

Comment 142

18 years ago
> this patch doesn't... actually let you send a PGP encrypted message.

I think you're missing the point here. There are going to be many *many* people
who download 1.0 and use it for a long time before upgrading again... 1.1 will
be too late. Get the encryption support to those users, and you will have
created a market for the NAI product. That plugin won't be written unless there
is a market for it.

Seize this opportunity, because it won't be coming around again for a long time.

Comment 143

18 years ago
Hi I'm Xose and I would like to add my comments as a user of Mozilla and its
mail component.

1. I think that Seth has done a good, job, although everybody seems to agree
that security should be implemented in Mozilla Mail/News.
2. When Mike says that "it's sad that 97 people will be disappointed in Mozilla
1.0 because of its lack of PGP support...", I would like to tell him that this
bug is the "most voted" in bugzilla, and as you know, users might not be
involved in that, they only want a project that works and they can feel
confident with it (PGP or S/MIME is getting very popular, as SSL is for
eCommerce). Mozilla Mail/News lacks that, and it's a shame that we have to try
to convince you that this is something very important for a Mail application.
3. I understand that you are very busy (who's not), but we are collaborating by
simply taking a lot of time to read the very long bug that this is (could we be
shorter in our explanations?, please!).
4. Mike, you're right, without the NAI plug-in it's useless all the effort that
has been done in this bug. I think a lot of work is already done, so can't be
targgeted for 1.0? Can't NAI release a plug-in for that?
5. You might take into account that this lack of S/MIME or PGP suport not only
prevents you from sending private emails to others, but receiving signed or
encrypted mail. What would make you think about which email program you want to use.
> this patch doesn't do what you think it does (though svn's might).
> It doesn't actually let you send a PGP encrypted message

Yes, this code does nothing at all without the corresponding binary plugin at
the PGP side (which in turn interfaces PGP). Also, PGP's plugin currently is
implemented only on Windows, but it seems that NAI might well produce one for
other platforms.

> Without the NAI plug-in it's useless all the effort that
> has been done in this bug

No, this work is not only useful with the PGP from NAI. As svn proved, it is
possible and not even hard to interface with gpg. He does it using ProtoZilla,
but I think it could as well be done with a direct API.

> Can't NAI release a plug-in for that?

It is my understanding that NAI has the plugin on their side implemented and it
only needs testing, for which this bug need to be fixed. They will release it
after that's done.

> I didn't follow the spellchecker checkin, but the details don't matter:
> if we bow to such things as precedent, we'll end up with a tree full of
> wallet.

The spellchecker was only one - the obvious, because related - example. The tree
is *full* of such examples - it is a commonplace.
I find it hard to believe that this will all change immediately from now on or
that this PGP plugin is a good start for a change in policy.

Facts are:
- Almost all open-source mailers hardcode PGP support
  I checked the source for Mutt, Pine, Tkrat 2 and Evolution. Standard-Pine
  has no PGP support at all, all others hardcode PGP support.
- Netscape Messenger 4.x hardcoded S/MIME support, as trails in older versions
  of Mozilla's libmime prove.
- NAI not being able to create a good UI for Netscape 4.x and 6 is one of the
  major blockers for wide PGP acceptance.


I filed bug 84570 about rudimentary composer plugins. If
- that bug were fixed
- the PGP plugin used it
- the plugin used XUL overlays
- the plugin used the current way to plug itself in libmime
, then I think this bug would leave no trails whatsever in a Mozilla without PGP
support. Would that be acceptable?

Comment 146

18 years ago
Would Bug 48374 need to be fixed for this to work?

Comment 147

18 years ago
hmm look what popped in mozdev.org:
http://enigmail.mozdev.org/

Comment 148

18 years ago
User interface comments from kuro5hin:
  http://www.kuro5hin.org/comments/2001/9/22/173430/188/37#37
'What we really need is a free mail package [...] that will automatically
generate a key. by default attach a public key to any message it sends, adds any
attached keys to a keyring, and if you send an email, it will give you the
option of "Postcard" or "envelope" mode.'

I think the postcard/envelope toggle is a good idea.
"postcard/envelope" is a nice wording, but generating keys automatically isn't
necessarily. See the discussion recently on n.p.m.crypto.

Comment 150

18 years ago
How about:

Postcard: no encryption
Envelope: 40bit encryption (can be read by determined snooper but takes effort)
Titanium box: 128bit encryption (more-or-less unreadable by anyone)

For things that I don't consider extremely private (passwords, credit card
numbers etc) I'd be happier using 40bit - at least that way if I were somehow to
lose my own private key through a disk crash or whatever, I'd have a theoretical
chance of getting my data back :)

But "envelope" as an analogy for 128bit encryption seems to be stretching it a
little, in terms of the level of security actually provided.

Comment 151

18 years ago
Voluntary weak encryption? What a terrible idea.
Considering that you can crack 40bit in realtime, I wouldn't anyone want to
trust his credit card details to such an obfuscation.

Even unencrypted mails cannot be seen by just anybody easily. You have to
intercept them. If you make that effort, you will very likely go the extra step
and break any weak encryption.
Plus, in 5 years what might be barely feasible for major governments today will
likely be trivial for anyone tomorrow.

Comment 153

18 years ago
Ouch, "NAI to Sell Off PGP Product Line"

http://slashdot.org/article.pl?sid=01/10/12/0129228&mode=thread

Comment 154

18 years ago
How about using GPG instead then?

Comment 155

18 years ago
They're NOT Discontinuing PGP:

" Network Associates will continue to sell and provide premier support for
products not integrated into McAfee or Sniffer. The Gauntlet Firewall and PGP
file and desktop encryption products will not be integrated. We will seek buyers
for these product lines who are best able to support the users needs. When a
company buys these products, Network Associates will work with them to provide a
smooth transition for existing customers and the acquiring company."

Comment 156

18 years ago
Since S/MIME encryption is now being actively worked on with experimental builds
available, that means that the architecture proposed here must have been
implemented, right? After all, if PGP couldn't go in without that architecture,
neither can S/MIME.

Am I right that the current work on S/MIME un-blocks this bug for someone to get
PGP/GPG working with Mozilla now? If not, why not?

(I don't *want* to believe there's a double standard being applied for features
that Netscape want versus features everyone else wants, so I really hope the
answer to this question is "yes, the architecture has been implemented, PGP can
be added now". I hope my faith in mozilla.org is justified... :/ )
>Since S/MIME encryption is now being actively worked on with experimental builds
>available, that means that the architecture proposed here must have been
>implemented, right? After all, if PGP couldn't go in without that architecture,
>neither can S/MIME.

right.  the architecture changes are clean.  the exception is what had to be
done to mime.  I'm not sure those hacks have landed yet.

>Am I right that the current work on S/MIME un-blocks this bug for someone to get
>PGP/GPG working with Mozilla now? If not, why not?

sure, someone need to step up and start hacking.  there aren't any docs yet,
those will come eventually.  you can look at how to extend the account manager
(#107068).  for the other extensions to compose and send, see #106507.

>(I don't *want* to believe there's a double standard being applied for features
>that Netscape want versus features everyone else wants

the only double standard is netscape supports ($) a good number of the
contributors, so they have the resources to get features implemented.  but they
still have to be done right.

>so I really hope the
>answer to this question is "yes, the architecture has been implemented, PGP can
>be added now". I hope my faith in mozilla.org is justified... :/ )

the architecture has been implemented, but not completely checked in. 
there's isn't much in the way of documentation yet, either.

Comment 158

18 years ago
That's great news! (Of course, the company that wanted to work on this has
discontinued their product, but it's the principle of the thing...)

Just to clarify, in light of your response I don't think that there was a double
standard at all. I was worried that S/MIME might have gone in *without* first
having to implement the architecture that was proposed in this bug, which would
have been a double standard because that wasn't permitted for PGP. But your
comments make clear that this isn't the case, so my faith in the process is
reaffirmed.

Thanks for clarifying; regardless of whether anybody steps up to this bug, it's
good to know that now at least they *can* :)

Comment 159

18 years ago
Are the S/MIME changes to mailnews being added in a generic fashion or in an
S/MIME specific fashion? In other words, can PGP/GPG support be also added using
the generic hooks introduced to accommodate S/MIME.

I looked at bug 107068, which seems to introduce generic hooks. However, I
couldn't figure out if bug 106507 was also using a generic approach.
Seth, which type of plugin architectures does the current patch implement?

The changes I saw so far
<http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=all&branch=PSM_2_2_DEV_20011002_BRANCH&branchtype=match&dir=mozilla%2Fmailnews%2F&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=month&mindate=&maxdate=&cvsroot=%2Fcvsroot>
hook directly into ns[I]MsgSend, ns[I]MsgComp* etc., just like the PGP patch did
which you critized. Maybe I overlooked it, but I didn't see the generic send
plugin arch. that you insisted on a few months ago.

However, apart from Stuarts's valid political concerns, I was never convinced
that this is the right approach anyway. The current Mailnews changes (the UI,
the Mailnews message APIs) talk about "encryption"/"signature" only, with no
mention of S/MIME specifically.

So, I hoped that Netscape implemented the generic crypto interface that I
proposed (which automatically encrypts/signs using S/MIME or PGP, depending on
the certs available), but it doesn't look that way either. Instead, right in
nsMsgComposeSecure.cpp, I see

PR_smprintf("Content-Type: " APPLICATION_XPKCS7_MIME"; name=\"smime.p7m\"" CRLF
                                          

and so on. It looks to me like the current S/MIME code has in fact much more
hooks into Mailnews than the PGP patch here does.

While I'd like to believe that there is a (generic- or crypto-) plugin
architecture, too,  I cannot find it. Maybe you can clarify this and point me to
the generic interface? (The account manager plugin interface (bug 107068)
doesn't count, because that code/UI wasn't even part of the PGP patch, IIRC.)

Comment 161

18 years ago
Ummm nsMsgComposeSecure is implemented in extensions/smime so of course it's
going to refer to smime directly. That file is SMIME's implemenation of our
secure send interface. 

If you will give us a couple days, once I'm done landing, I'm planning on
writing up a document describing our pluggable infrastructure for crypto engines
in compose. You'll notice that everything that went into mailnews/compose is
complete generic. There is no SMIME stuff in there. The smime specific UI and
implementation is in mailnews/extensions/smime. That's where all the UI
overlays, property files, creation of a security object which gets passed along
on the send all exist. 

The architecture is extremely pluggable and I will step you through it when I
write up a document. So please wait until then before jumping to conclusions by
looking fragments of a partial landing (I haven't even checked everything in yet). 

Thanks!
> Ummm nsMsgComposeSecure is implemented in extensions/smime

No, it's in mozilla/mailnews/compose/src/nsMsgComposeSecure.cpp. The link I
posted above lists changes to the Mailnews code (CVS dir mozilla/mailnews/) *only*.

> You'll notice that everything that went into mailnews/compose is
> complete generic. There is no SMIME stuff in there.

Everything I was talking about above (incl. the cited code) is in mailnews/, not
extensions/.

> The smime specific UI and implementation is in mailnews/extensions/smime

The UI <http://www.mozilla.org/mailnews/specs/security/> makes this not all
clear to the user. It allows the user to "encrypt", implying S/MIME.

> The architecture is extremely pluggable and I will step you through it when
> I write up a document. So please wait until then

Shouldn't we have a chance to review the design before it gets checked into the
trunk?

Comment 163

18 years ago
>No, it's in mozilla/mailnews/compose/src/nsMsgComposeSecure.cpp. The link I
>posted above lists changes to the Mailnews code (CVS dir mozilla/mailnews/) *only*.

I see no such file getting built by mozilla. lxr is showing me that file in
mailnews/extensions/smime/src which is where I put it.

Comment 164

18 years ago
ben you are looking at an obsolete branch, discussion about the code in that
branch is not going to be very productive since it doesn't reflect reality. Why
don't you look at the changes in mailnews/compose and mailnews/extensions/smime
that are on the trunk right now? 

Updated

18 years ago
No longer depends on: 56052

Updated

18 years ago
Depends on: 56052

Comment 165

18 years ago
Hello everyone. Just thought I'd ask what the latest status is of 
the "pluggable crypto architecture" that S/MIME is using or is going to be 
using. Oddly enough, I may be working on this plug-in again, depending on how 
things go with the sale of PGP to another company. If PGP gets a buyer, and if 
the buyer hires me, and if they are interested in doing a Netscape plug-in, 
I'll attempt to pick up this work again.
As I understand it, the work the Mail team requested has mostly been done, so
adding PGP support in an acceptable way should be a lot easier now than it was.

However, the 1.0 focus is on performance, speed and stability, not on new
features, and I think that, by the time a new patch arrives, we'd probably be
looking at integrating it in a post-1.0 timeframe.
Gerv
Lot's of folks want this. If it gets done and builds cleanly as an optional
component, and the default is not to build it, I don't see why it would
necessarily have to wait for 1.0 since under those conditions it wouldn't really
have an impact.
In fact, there is already an IPC-based PGP mail extension on mozdev:
http://enigmail.mozdev.org.  I guess that means it's possible. =)
Status: NEW → ASSIGNED
mscott wrote in comment #161:
> If you will give us a couple days, once I'm done landing, I'm planning on
> writing up a document describing our pluggable infrastructure for crypto
> engines in compose.

Did you get around to write it?
see http://www.mozilla.org/mailnews/arch/pgp-smime.html

This should give anyone who wants to add PGP support into mail some initial
background on how S/MIME support was added, which bugs and patches to look at,
and where they should start for PGP.

note, this doesn't cover how enigmail works.
> 5) The compose UI is done using overlays and XPCOM tricks.  
> 6) The only hacked in part was to the mime back end. 

Isn't that exactly what I proposed in comment 135 and comment 144?
Found the following comment in libmime's mimeunty.h:
   Adding other types than uuencode to this (for example, PGP) would be 
   pretty straightforward.
(This might help avoid the registering/unreg hack that Demon had to use to find
PGP messages in plaintext parts, assuming PGP is allowed to hack that file.)

Comment 173

18 years ago
So, looking at the mozilla milestone doc, this work needs to be done ASAP if
it's got a chance in heck of making 1.0.  It seems like all the blockers have
been taken care of.  Who's working on this/where should I pick up the pieces
from if I want to pull it together myself?
This won't make Mozilla 1.0, believe me -
http://www.mozilla.org/roadmap/mozilla-1.0.html . See the list of 5 criteria
under "who". :-)

Gerv
The PGP/MIME standard should be supported. Gnus does this, too. It uses a
installation of GnuPG or PGP (using a wrapper not in the Gnus package).

Comment 177

17 years ago
As there seems to be resurgent interest in a PGP plugin for Mozilla, I just
thought I'd let those cc'd on this bug know that Enigmail
http://enigmail.mozdev.org
has improved dramatically over the last couple of months and is being used by
several people.Enigmail encrypts/signs/decrypts/verifies plaintext mail,
imports/exports keys etc. using command-line PGP/GPG, without any modifications
to the Mozilla code.

Enigmail doesn't support PGP/MIME or encrypted attachments, and will not be able
to do so until this bug is resolved, of course.
*** Bug 142605 has been marked as a duplicate of this bug. ***

Comment 179

17 years ago
I'd just like to second the whish of the bug author: it would be _very_
important to have proper PGP integration into mozzila.

Comment 180

17 years ago
Any thoughts on resetting the keywork from mozilla1.0 to mozilla1.2 or so?

Comment 181

17 years ago
Update from Enigmail:

Following Ben Bucksh's suggestion about using external MIME content handlers,
Enigmail now supports both inline PGP and PGP/MIME. This means Enigmail now
provides most features that PGP/GPG users would expect from an MUA, and a number
of people have been using it on a variety of platforms (Windows, Linux/x86,
Linux PPC, FreeBSD).You can download a version for Mozilla 1.0 from
http://enigmail.mozdev.org/download.html

I would be be quite happy to see the Enigmail code integrated into the post-1.0
Mozilla CVS trunk at some point. The most commonly reported bugs for Enigmail
have to do with installation issues and binary DLL incompatibilies, which would
go away with integration. I would like some feedback from the Mozilla Mail/News
developers and module owners on this. Integration will only happen if one or
more Mail/News developers are willing to spend some time on some thorny
integration issues. It's not just a matter of checking in a huge patch.

The code that implements PGP/MIME, which basically "piggy backs" on to the
S/MIME code, can be found at
http://www.mozdev.org/source/browse/enigmail/src/src/
Integration should be fairly straightforward for PGP/MIME. However, the inline
PGP implementation code is messy and fragile. Some small, but important, changes
will need to be made to the base Mail/News code to provide inline PGP support.
Since more MUAs support inline PGP than PGP/MIME, this is an important issue.
The UI integration will also be tricky since S/MIME and PGP use very different
trust models.

Enigmail uses inter-process communication (IPC), and the code to implement IPC
was submitted about a year ago
http://bugzilla.mozilla.org/show_bug.cgi?id=68702
and has been in limbo for a while. With that experience, and with Damon
Gallaty's experience documented in this bug, I am not too optimistic about
seeing PGP support integrated into Mozilla in the near future. Nevertheless, I
feel that I should make an attempt.

If there is some positive feedback from the Mail/News developers, we can begin
to discuss the integration issues, and perhaps open several "smaller" bugs for
the technical stuff, leaving this as a tracking bug. If someone would like to
provide an alternative to the Enigmail codebase, this would be the time to
discuss that as well.

Comment 182

17 years ago
Looks like some impressive work has been done on Enigmail. I'd just like to
advance an idea no one else seems to have mentioned (according to accel-f).

R. Saravanan says the inline PGP code is "messy and fragile" and requires core
chances. Since Mozilla is targeted at developers and OSS users anyway, in which
communities inline PGP is already heavily frowned apon, it would be a great move
for Mozilla to take the standards highroad here again and only send and
interpret PGP/MIME messages. Mutt does this (excluding hacks), and I've never
had issues, nor want for support of deprecated inline PGP.

Mozilla already has enough backwards compatible cruft. We don't need to
encourage non-standard PGP messages as well.
I think he refers to the reader (being able to read/check inline PGP msgs), not
the composer (being able to send them).

Comment 184

17 years ago
Whatever happens, please let it not be restricted to PGP/MIME only.  PGP/MIME is
great if everyone you are communicating with has it working.  If this is not the
case, then you are in for a nightmare of incompatibility.  Everybody, from the
most advanced MIME-savvy power user, down to the guy still running Berkeley
mail, can handle an inline signed message.  This isn't even vaguely true for
PGP/MIME.  By all means support PGP/MIME, but not at the cost of removing inline
support.

This thread on the IETF OpenPGP working group mailing list says a lot:
http://www.imc.org/ietf-openpgp/mail-archive/msg03786.html

Comment 185

17 years ago
I'm curious, doesn't this allow ingoing/outgoing body message filtering through
an externally defined command?

That functionality would allow everything: tagline rotation, PGP support,
Mozilla-side external spam filtering, etc.  In an easy way.

Comment 186

17 years ago
Also, MS Outlook doesn't behave nicely when it gets PGP/MIME attachments: it
displays the actual content of the message as an attachment, rather than inline,
and thus Outlook users who've been trained to avoid viruses by not opening
attachments never read the message.

This is, of course, a bug in Outlook, but it'd be a shame for Mozilla to be
sending mail that lots and lots of people can't read. The workaround for people
would be to turn PGP off, which defeats the whole purpose of having a PGP plugin.

Comment 187

17 years ago
I would agree with dshaw that if and when Mozilla supports PGP, it should
support both inline PGP and MIME, as does Enigmail now. However, it is not no
longer true that inline PGP is easy to handle or that it is "universal" in any
sense. Inline PGP works best when the pure MIME type "text/plain" is used.
However, modern mailers tend to use convenient features like flowed text (RFC
2646), quoted-printable encoding, and "text/html", all of which can, and do
really mess up inline PGP.Attachments are also much more common these days.In
other words, inline PGP is much more fragile now than it used to be just a few
years ago. If PGP/MIME doesn't catch on, PGP mail will slowly die.

Newer GUI mailers on Linux seem to be supporting PGP/MIME, e.g. Evolution, new
KMail etc. The main problem is the lack of PGP/MIME support for Outlook/Outlook
Express on Windows.

Comment 188

17 years ago
Please support InlinePGP. 50% of the email I receive is in fact InlinePGP. (one
of the perks of being on debian-devel-changes mailing list)

In addition to the many valid reasons already specified above, it is much easier
for quickly written scripts to parse and verify InlinePGP messages (simply
piping to gpg) than it is PGP/MIME. Of which I would have no clue how to do
manually. (pardon my ignorance)

AFAIR, when Debian held their project leader election this year, all developers
emailed their votes in an inline pgp signed message to the voting email address.
These emails were then run through the voting script and verified against each
developers gpg/pgp key. The voting instructions explicitly required inline PGP.
Having to support PGP/MIME would have made the script needlessly more complicated.

I use Mail.app/GPGMail on Mac OS X as my primary mailer. The number one reason
for this is Mozilla's lack of PGP support. Adding PGP support sans inline would
not meet my needs and further prohibit me from making Mozilla my primary mailer.

Comment 189

17 years ago
I want to clarify one of R. Saravanan's comments, as I both disagree and agree. :)
We need to distinguish between encrypted messages and clearsigned messages.  By
definition, an ascii-armored encrypted text "blob" is US-ASCII 7-bit text with
short line lengths (and spaces are ignored in any event).  There is no issue
here: send it text/plain and no fancy magic and you're done.

Clearsigned messages are different as they mix the user's text along with an
ascii-armored blob at the bottom.  Both parts must survive for the message to be
usable.  If the user is using US-ASCII then there is no issue (luckily this is
the huge majority of cases).  When that is not the case, some care needs to be
taken between making the signature usable and making the text readable for the
non PGP-user.  This is not impossible - the newer versions of mutt do exactly
this, and it amounts to mostly character set encoding issues.
The DPL election did not require inline gpg in any way whatsoever. Mutt doesn't
support non PGP/MIME at all, and that's the de facto standard for Debian
developers; I myself signed my ballot with mutt.

Updated

17 years ago
Blocks: majorbugs

Comment 191

17 years ago
*** Bug 130382 has been marked as a duplicate of this bug. ***

Updated

17 years ago
Alias: pgp

Comment 192

16 years ago
I'm just being curious what the status on this bug is?

Are going to use Enigmail as the PGP plugin? Are there still plans/wishes to
integrate Enigmail with the trunk? What's going on out there? :D This bug has
been silent for almost a year now and still has over 400 votes :D

Comment 193

16 years ago
Worse than that (comment #192) at the time of writing, there is ONLY ONE bug
with more votes than *this* one. And bug #18574 only has 4 more votes than this
one (which I just voted for :-D ).

Kinda makes the whole voting thing seem silly.

BTW I'm using Enigmail with *great* delight.

Why can't we just merge Enigmail into trunk?
The first question is, do the Enigmail authors WANT their code merged into the
trunk?  They sorta have to give permission for that, and I don't see them doing
that anywhere in this bug.

Comment 195

16 years ago
Comment 181:
"I would be be quite happy to see the Enigmail code integrated into the post-1.0
Mozilla CVS trunk at some point. The most commonly reported bugs for Enigmail
have to do with installation issues and binary DLL incompatibilies, which would
go away with integration. I would like some feedback from the Mozilla Mail/News
developers and module owners on this. Integration will only happen if one or
more Mail/News developers are willing to spend some time on some thorny
integration issues. It's not just a matter of checking in a huge patch."

So it's not about what the enigmail devs want it, it's about the mail/news devs..
Maybe the summary of this bug has to be changed? There is a plugin for it at the
moment ;)
Seth?  Scott?  Could you possibly get in touch with the enigmail people and find
out what issues need resolving before enigmail can be merged into the trunk?

Comment 197

16 years ago
Despite any technical aspects I think that integrating Enigmail as it is right
know would produce a usability issue. The appearance of Enigmail seems a little
bit too "branded" for a simple sign/encrypt function within Mail/News. For a
plugin that people download/install, that's OK, but for a function, it is not.

So I think that the "Enigmail" menu shouldn't remain. So shouldn't the
"Enigsend" function. Sending a mail encrypted is probably the far less used
function, compared to sending unencrypted, unsigned, plain text mail. With
enigmail, sending encrypted mail becomes the default function for adresses where
a public key is available. This bug me as a user of enigmail.

To sum this up, I would love to see the PGP functions become part of Mail/News,
especially to make use of encryption in E-Mail more popular, but it should be
integrated more seamlessly than Enigmail is right now.

Comment 198

16 years ago
Quoth marian@sendung.de:

    With enigmail, sending encrypted mail
    becomes the default function for adresses
    where a public key is available.

I'm not a user of Enigmail, but the screenshot of the preferences has a checkbox
of ``Encrypt mail if possible.'' This would seem to address your biggest complaint.

Cheers,

b&
Being one of the current maintainers of Enigmail, I can say, we still would not
mind to see Enigmail incduded in the normal Mozilla tree. However, this is not
on us Enigmail developers to decide. I should also say that in the current state
Enigmail, there are quite some hacks needed to make Enigmail work at all.
Therefore I would not recommend it to be  integrated into the trunk without a
number of changes! 

The good news is that Scott and I have started (off this bug) to discuss what is
needed in a first step for a better integration of Enigmail into Thunderbird to
overcome the current problems (i.e. to get rid of the hacks). The idea is that
Enigmail should be more an "extension to Mozilla that does PGP encryption", than
a "plugin called Enigmail" as it is right now.

See also http://www.mozilla.org/projects/thunderbird/specs/extensions.html
*** Bug 210253 has been marked as a duplicate of this bug. ***
*** Bug 210255 has been marked as a duplicate of this bug. ***

Comment 202

16 years ago
I would like to know, if the enigmail extension ready yet to be included in the
Mozilla Main.

And what is the mozilla Main Discussion?

Comment 203

16 years ago
To respond to the last comment, I think once they switch over to the
Firebird/Thunderbird structure, enigmail will be an extension.  Secondly, for
Linux I use Gentoo, and the Enigmail is an option during the installation.  For
Windows, I think a smart thing to do would be for someone to make a new Mozilla
installer which has a "custom install" option.  During the custom install
process, the user could be asked about all sorts of extensions....  Someone
within the mozilla project could do this, or someone not involved with
mozilla.org directly.  But that is the future I think, to move away from a
non-bloated mozilla and have extensions... all we need is a fancy installer.
We have already "switched over to the Thunderbird/Firebird structure", that's
the least problem. From a GUI / use point of view, I think Enigmail now fits
quite nicely into the Thunderbird look&feel.

But before incorporating Enigmail into the Mozilla trunk, still there need to be
some changes done in the existing Mozilla code. The current implementation of
Enigmail is still in many parts based on workarounds "against" Mozilla.

Updated

16 years ago
Summary: [RFE] PGP Plugin → PGP Plugin

Comment 205

15 years ago
Suggestion: when the integration of enigmail is finally done, I recommend to at
least think about using the tight combination of GPG and ThunderBird to
establish  trusted networks of pgp key owners. Example: the user gets shown a
simple key generation and information dialog after he has entered his mail
account information. Additionally, if he decides to not create or import a key,
the dialog should pop up again after a software update.

Intent: if many emailers sign their mails and have trusted keys, we hopefully
can send all spam(mers) to /dev/null. I know that there are server-side methods
like domain name keys, but doubled security against those idiots is always
better. Additionally, I'm not too convinced that server-side protection really
works. I'm not exactly an expert in that field, but doesn't the spam problem
originate largely from mail servers that aren't correctly configured or have
proper usage policies applied?

Comment 206

15 years ago
> Intent: if many emailers sign their mails and have trusted keys, we hopefully
> can send all spam(mers) to /dev/null.

As much as I agree with you in terms of "people should sign and crypt their
mail", I have to ask myself why signing mails should be of any help fighting
spam? There is no problem in faking (or even creating a real) signature. Why
should a spammer not put just a GPG Signature under his Mails?

Comment 207

15 years ago
> I have to ask myself why signing mails should be of any help fighting
> spam? There is no problem in faking (or even creating a real) signature. Why
> should a spammer not put just a GPG Signature under his Mails?

Yes, he can. He can even invent a new personality for each spam he sends.

But he cannot impersonate anyone else (so if you get a signed message from
someone you know you know it is not spam (unless the person is sloppy with their
key)).

And - more importantly - PGP can be used to build "webs of trust". The current
WOT is used to establish "real world" identities - but that isn't the only use.
You could build a WOT where the trust metric signifies "writes interesting
emails". If you receive a message from a stranger, you can estimate whether the
message is interesting to you from the path of signatures. I wrote up my ideas
about this topic some time ago:

http://www.hjp.at/projekte/mail-wot/outline.rxml

Comment 208

15 years ago
(In reply to comment #207)
 
> But he cannot impersonate anyone else (so if you get a signed message from
> someone you know you know it is not spam (unless the person is sloppy with their
> key)).

That sounds like some sort of Whitelisting. Nothing new to invent here... If you
filter on everybody you don't know, or on everybody's key your don't know does
not make any difference...

And for Evaluating the GPG Signature you have to download the signature and
therefore the whole mail... Maybe I got you wrong?

Comment 209

15 years ago
[I suspect we are getting a bit off-topic here. However, since en E-mail web of
trust needs good integration into the MUA to be useful, it is related to the
existence and capabilities of the PGP plugin. So I'm keeping it here - if it
becomes too long, we should probably take the discussion to a mailinglist or
newsgroup]

> That sounds like some sort of Whitelisting. Nothing new to invent here...
> If you filter on everybody you don't know, or on everybody's key your don't
> know does not make any difference...

There are two key differences:

1) The Return-Path and From header in a mail are completely under the control
   of the sender - there is no way to verify them. How many viruses have you
   received over the last year claiming to come from a friend? A whitelist based 
   on the unverified sender address won't catch them. If the message is signed, 
   however, the whitelisting can be based on the signature, which is difficult
   or impossible to fake.

2) I didn't propose blocking all mails with unknown keys. Rather I propose using
   the web of trust to compute a "probability" that the mail is interesting to
   the recipient. I described this a bit more detailed (although not yet 
   detailed enough to implement it) at the URL I provided, but in short the idea
   is this:

   Everybody signs the keys of people he corresponds with. Optionally, the
   signature can contain a rating ("he writes interesting stuff 60% of the 
   time")

   The Keys and signatures form a graph or web, just like the normal "Web of
   Trust". If a recipient doesn't know the key of a sender, they can search the
   graph for a path from the recipient's key to the sender's key. (see 
   http://the.earth.li/~noodles/pathfind.html for an example of a PGP path
   finder). The ratings along the path and the path length can be used to 
   estimate a rating for the key. Something like "Well, I don't know Alice, but 
   Bob and Clara know her, and they say, she's not a spammer, and I know them, 
   and I trust their judgement"


> And for Evaluating the GPG Signature you have to download the signature and
> therefore the whole mail... Maybe I got you wrong?

Well, Mozilla (Thunderbird) is a MUA, so it deals with messages which have
already been accepted by the MTA and stuffed into the user's inbox. The
signature verification could be done in the MTA, but that's beyond the scope of
a mozilla bug, so let's stick to how it could be implemented in Mozilla:

I think it should be done similar to the bayesian filter: When Mozilla opens the
 inbox (which is typically on a pop or imap server) it verifies all new messages
and marks them according to whether they have a signature, whether it is known,
and their rating. This can then be used as input into the normal filter
mechanism, and the user can override the estimate (thereby supplying his own
rating).

[It may be possible to make a prelimary check by downloading just the headers or
just the signature first - I'm not sure whether the bandwidth saving is worth
the hassle]

To make the system usable, the user also needs an easy way to sign keys and
upload signatures to the keyservers. That would also have to be added to the GPG
plugin (if it isn't already - I admit I haven't looked at it for some time).
Please keep anti-spam discussion off the bug. thanks.

Comment 211

15 years ago
I think the anti-spam discussion is rather interesting, and topical.  I don't
know of any other MTA's that integrate GPG in this manner.  And since it doesn't
appear as though mozilla is *ever* going to include enigmail anyway OR its own
implementation, where's the harm?  Frankly, I'm surprised this bug hasn't been
closed WONTFIX by now.

Comment 212

15 years ago
This bug is about PGP support, NOT anti-spam measures, so discussions about
fighting spam are out of place here and border on being spam themselves.

At this stage of development this is likely something that should be handled as
a ThunderBird Extension rather than as an addition to the Mozilla Suite. Bearing
that in mind it's time to mark this bug won't fix.
Product: MailNews → Core
(In reply to comment #212)
> At this stage of development this is likely something that should be handled as
> a ThunderBird Extension rather than as an addition to the Mozilla Suite. Bearing
> that in mind it's time to mark this bug won't fix.
    Handling it as extension leads to problems like this:
--- cut from fedora-devel ---    
Normally enigmail not loading means mozilla was built with
--disable-shared or without --enable-crypto. The fedora build appears
to use both. It will install enigmail but then complains about
enigmime not being available but in new versions of enigmail, enigmime
is built in.
--- cut from fedora-devel ---    
    The problem they see are the different release cycles. For more info follow
the thread at
https://www.redhat.com/archives/fedora-devel-list/2004-December/msg00149.html .

Comment 214

14 years ago
Hi. Any development?

I suggest you to integrate Enigmail + gnupg into Thunderbird.

Comment 215

14 years ago
(In reply to comment #214)

> I suggest you to integrate Enigmail + gnupg into Thunderbird.
                                        ^^^^^
TheBat! (Windows) brings its own internal OpenPGP implementation and also offers
to use any preinstalled GnuPG (and other implementations) once it sees them on
the $PATH.

Roland.

Updated

14 years ago
No longer blocks: majorbugs

Comment 216

14 years ago
(In reply to comment #214)
> I suggest you to integrate Enigmail + gnupg into Thunderbird.

Does GnuPG work on all Mozilla platforms?

In order to avoid export restrictions and/or any other cryptographic
restrictions, it might be better only to integrate Enigmail and let users
themselves install GnuPG if cryptographic support is required.

Comment 217

13 years ago
I believe that implementation for this RFE might be impacted by bug #285715.  

OpenPGP (RFC #2440) depends on the message not being altered by the E-mail client, either in sending or receiving.  For receiving a message, the user must rely on the E-mail client not to make any alterations in any characters, including insertions or deletions.  Bug #285715 reports that such changes are indeed happening when the message is displayed.  The raw ASCII source of the received message is not affected.  However, the question is whether the displayed or source message is what would be used by a plug-in.   
It was hinted at back in 2004 that this bug should probably be closed as WONTFIX seeing that there is good support for it in an extension (enigmail). Could someone please do so.
> this RFE might be impacted by bug #285715.

No, that is not a bug at all, and nor would an OpenPGP be impacted by what's described there, because it would of course check the message *before* the view formatting happens.
I would also think that - for a similar reason - the f=f problems with enigmail would be solved more easily when this was supported bettwe in core, because extensions have limited abilities to tap into the message decoding.

Comment 220

12 years ago
!!!!!!!!WOW!!!!!!!!
It is impressive that this bug is about 7 years old!
It sure has my vote!
Can anyone tell me:
How can i get pgp gpg or whatever up and running on my thunderbird today?

Is there a link that i may follow that gets it up for me as simply as possible?

Thanks in advance.

Comment 221

12 years ago
glenn:
There is the EnigMail extension at http://enigmail.mozdev.org/ which adds PGP functionality to Thunderbird.

Comment 222

12 years ago
(In reply to comment #221)
> glenn:
> There is the EnigMail extension at http://enigmail.mozdev.org/ which adds PGP
> functionality to Thunderbird.
> 
Thanks:  I have tried Enigmail.  It maybe  works sorta, but i have not gotten it to work well enough to be able send secure comm to anyone!( i am sure that this is my fault in that i do not know what is required to make secure comm happen-- but then again if it worked like a toaster i could just push the button). 
IT IS TOO COMPLICATED for most people to actually use in everyday traffic!!!

It needs to be automated!
But as part of the browser there are many things that could be done to make it easier to ROUTINELY communicate securly with most of the world at large.

(Security in encryption is enhanced by increasing the sheer volume of encrypted traffic to include the mundane and the precious)
The browser would setup the info for basic communication like it does email (All without me having to know how the file systems work or how to do binary arithmatic or paginate etc....)
first it could setup all users by default with the ability to receive encrypted mail transparently to the user without any further effort by the user. it could have a standard public key repository to which public keys would be by default be sent.  

There could be private key negotiation required in the back ground via public key infrastructure. :
	john's browser sends his public key to the public key ring.
	Alice's browser sends a request to the public key ring for a private key to send messages to john in john's preferred key length. IT includes Alice's export signature and john's import signature so that john's browser is sure that Alice is the sender and that he is the intended recipient. once the browsers are in agreement, the browser informs the sender and recipient that messages in future will be sent in encrypted form and the quality of this encryption based on #of years with the fastest computer network envisioned in that length of time(ala Moore's law) and some estimate of how large cryptologist's computers (networks) currently (in worst case estimate) are. Either can renegotiate for more secure comm with the browsers.

Routing addresses could even be securely be done by encrypting the path onion-layer style and then having the opening of the onion-layer having the recipient open at the last recipient router which would not know the path traversed.(yeah I know this increases the privacy and cost of spam for the recipient as well as the sender! 

The other really bad thing is that if done ok but notso well is that it would become a not so good defacto standard!

I believe that if Mozilla will just say ok we'll do it the community will put it together. even if the files have to be imported from Germany  or Switzerland for each build to avoid us export regulations or whatever!

This is a bug with major security implications and i hope someone decides to improve its profile.
And it has huge numbers of votes! :)

MOZILLA THUNDERBIRD and others: Thanks in advance for your consideration.
> IT IS TOO COMPLICATED ... It needs to be automated! ... like a toaster

Not even a toaster is automated, mine needs the right setting adjusted per bred type.

Seriously, PGP *cannot* be automated, because you need to create a key and *save* it, not lose it. If you create a new key every time you set up Thunderbird, your readers cannot know when a key change is an attack or you just reinstalled your computer or whatever. Thus, PGP gets useless if there are many people flooding with new keys all the time.

Thus, creating a properly working PGP plugin for the masses who have no clue about what a "cryptographic key" is (no, not any will do), is very hard UI-wise. 

Everybody: In general, please refrain from comments unless you can significantly contribute to the implementation and design.
(Thunderbird can help creating and importing one, but not saving it. Wizards can make it all easy and can even explain the reasons, but are helpless against the vast majority of people who simply don't *read*, just click through.)

Comment 225

12 years ago
The PGP product (from PGP, Inc.) has a capability in Windows to encrypt, decrypt, sign, and verify signatures for the current window.  Click on the message window to make it "current".  Then right-click the PGP icon in the Tray and select Current Window in the pull-down menu.  You get a submenu with "Decrypt & Verify" (which will do both or either, depending on what is in the current window), "Encrypt & Sign" (do both), "Encrypt", and "Sign".  

I've given up on waiting for a plug-in.  I just want Mozilla mail applications to provide the proper content in the message window and the proper sending of messages to allow PGP to work.  That means addressing bug #285715 for in-bound messages (in the message window without having to resort to viewing the message source) and bug #98397 for out-bound messages.  
Status: ASSIGNED → NEW

Updated

11 years ago
Flags: wanted-thunderbird3?
Flags: wanted-thunderbird3.0a1?

Updated

11 years ago
Flags: blocking-thunderbird3?
Flags: blocking-thunderbird3.0a1?
I'm going to minus this bug, because the scope of work involved in fixing it makes it too large to consider for the Tb3 timeframe, even assuming there was consensus on what the right outcome is.  

I'd like to move the security/privacy issues forward, but at this point I don't see how Tb3 can be the right release for this bug.

Comment #225 implies that bug #285715 and bug #98397 should be in Tb3, in which case those bugs should be nominated wanted-tb3?, reopening as necessary.

Flags: wanted-thunderbird3?
Flags: wanted-thunderbird3.0a1?
Flags: wanted-thunderbird3.0a1-
Flags: wanted-thunderbird3-
Flags: blocking-thunderbird3?
Flags: blocking-thunderbird3.0a1?
Flags: blocking-thunderbird3.0a1-
Flags: blocking-thunderbird3-
Bug #285715 is invalid, which I think is correct. However, especially in order to decrypt or verify inline PGP some new API to get the unmodified plaintext body of an email could help a bit.
Duplicate of this bug: 276073
Duplicate of this bug: 437525
Patrick: sounds right to me. Can you file a separate bug on that and CC jminta@gmail.com -- this sounds like it might want to be part of STEEL.

Updated

11 years ago
QA Contact: lchiang → security
Product: Core → MailNews Core

Updated

11 years ago
Blocks: 448964
Assignee: ducarroz → nobody
Priority: P3 → --
Target Milestone: Future → ---

Comment 231

10 years ago
In November 2007, the IETF released RFC 4880, OpenPGP Message Format. 

http://tools.ietf.org/html/rfc4880
Ben Laurie and Rachel Willmer are working on a BSD-licensed PGP library should we want to build-in our own: http://www.links.org/?p=496
http://openpgp.nominet.org.uk/cgi-bin/trac.cgi/wiki/V0.9

Comment 233

6 years ago
Can someone please clarify:

* Is this bug about having a PGP plugin available, as its title and description says? Then why isn't it closed, since we have the Enigmail Add-on?
* Or is it about distributing Enigmail together with Mozilla Thunderbird?
* Or is it about incorporating Enigmail into the Mozilla trunk, which is also discussed in the comments?

I assume that none of the latter two will happen, since Mozilla has stopped further Thunderbird feature development. So in this case I also suggest to close this bug.
This bug is about native PGP support in Thunderbird, on the same level as S/MIME.
And no, it's not a wontfix, otherwise all new features would be wontfix.
In fact, it's more needed than ever.
It's about having PGP capabilities in core, be that by distributing Enigmail or not.

Thunderbird feature development hasn't stopped, it just have to be done by a volunteer contributor.
Duplicate of this bug: 887267
Duplicate of this bug: 1117533

Comment 238

4 years ago
Wow - i didn't see that this "problem" exists still 1999!
Otherwise i did not have opened my bug 1117533.

And it seems that it is simply "forbidden" to implement cryptography directly here in Thunderbird.
Of course it is forbidden and not wanted, because it would really be used then.

That's what the NSA is most feared ever!
GnuPG and TOR are the last things they could not infiltrate.
And still if GnuPG would be broken, the needed computing capacity for the mass would blast the observation away.

But that's exactly what is needed at this time!

The functionality of Thunderbird is mature, but this point is really needed in the basic functionality.

GnuPG should not be part of Thunderbird, but an easy direct way to use it.
The Enigmail plugin is to complicated for the masses.

Comment 239

4 years ago
Here my thoughts how to implement GnuPG in Thunderbird.

The main thing is to enhance the assistant for a new email account:

1. "Do you want to use encryption for your email privacy?"
no  -> everything is like before
yes -> check if GnuPG is installed

2. User want to encrypt mails and is GnupG installed?
no  -> detailed descripton how to install GnuPG, after that restart of assistant
yes -> goto 3.

3. Normal enter of the email address then check if an key exists (local and keyserver) ?
no  -> Generate key for the email-account
       * suggest best parameter for encryption
       * ask for passphrase and explain it
       * ask for upload of the public key to keyserver and to backup your keyring at a secure place
yes -> check if private key exists to deccrypt mails
       no  -> user must import private key from backup or a new key must be generated
       yes -> everything is fine


The account settings for an email must include the options for the encryption.
Emails keep stored encrypted.
There should be a general option to hold the passphrase in memory or not for extended security.
Every opened email is decrypted and viewed automatically.
Every send email is encrypted automatically with the public key of the destination email address.
A send email is stored encrypted too.


If Mozilla will not feel responsible to implement this, there should be a branch for a secure Thunderbird like the browser for Tor.

Maybe there is some help from Mozilla how this can be implemented?
What are the names of the source-files and entry points to implement this?

Comment 240

4 years ago
You shouldn't ask if people want to do stuff securely, it should just simply be done.

http://pep-project.org is a great concept to borrow stuff from.

Keys are automatically imported if found in a received e-mail, key-servers are avoided if possible to protect your social graph. Keys are created for you, they are used if the recipient is known to have pgp.

Maybe GPG can even be avoided once https://bugzilla.mozilla.org/show_bug.cgi?id=865789 is completed.
If so, the work should be done there first.
The crypto-API has nothing to do with OpenPGP.

Comment 242

4 years ago
> You shouldn't ask if people want to do stuff securely, it should just simply be done.

It should, but Thunderbird maybe used for other purposes where it is not needed.
Like intern mail or a mail account that will handle only not encrypted emails like system generated emails.

The important point is that the standard way of an email client is to work encrypted in an easy way.
No one will use it if he must do additional things like installing and using a plugin.

I have experienced this in a big company where every external mail have to be encrypted but nobody was doing it. The plugin was installed, but no key generated for the accounts.
There was no help what and how to do it.

It's the same with Thundebird.
There is an assistant that will help you to use an existing email account.
In the same way there must be a natural easy way to use encryption.
The problem was that nobody was understanding the encryption process and that he must do additional things for it.

Comment 243

4 years ago
Besides - it's a good question if you need a cypto-API for Outlook, because Microsoft always suffers a way for NSA access to an exchange server respectively it's encryption.
Have a look at the Snowden documents.

So if you want to have really email privacy you can't use Microsoft software.
I think there are some nice parallels to PDF.js. It was developed into a stable, user-friendly plugin that ultimately saw integration into Firefox releases, even though it is a considerable amount of code. I can imagine the same for Enigmail being integrated.

To make it user-friendly one really has to start with sane defaults that 95% of users will use, and a non-intrusive workflow. I think Enigmail currently offers too many options to the casual user that are irrelevant. A stupified interface would help: 
Installation as mentioned above, with the least amount choices/actions the user has to make. 
Settings: There are no settings that a casual user ever has to modify. Also, the only item from the "Enigmail menu" that a user ever needs is "Key management", which can go into "Tools". I think the Key management dialog may be ok already. 

There is considerable danger of bike-shedding here, so I think the Enigmail bug tracker may be more appropriate (https://enigmail.net/support/bugs.php).

The Enigmail community seems to have made major strides already to make Enigmail more user-friendly and to simplify its interface. I think any effort to integrate Enigmail into Thunderbird has to see considerable effort from their end (so join them), because they will have to do the long-term maintainance (development and user support). 

The stage of integration would need considerable effort by the Thunderbird community, and an ok from the regular contributors (because they will do testing, shipping and maintainance). Read this bug:
  http://sourceforge.net/p/enigmail/forum/feature_requests/thread/2e92a3b3/ 
and you will see that this the crucial point and why Enigmail has not been integrated (in the view of Enigmail developers).
The question is not whether we (the Enigmail developers) want to integrate Enigmail into Thunderbird. In the past, all our requests or proposals to integrate Enigmail were rejected.

Comment 246

4 years ago
Thank you for this comments opening my eyes.
Specially the corresponding bug report at sf.net is heavy stuff, because the behaviour of the Mozilla team is not understandable.
When we are talking of profits there is only one reason left why enigmail will not be integrated ... :-(

I agree that the work is mostly done by Enigmail (although i did not test the latest version so far).
But it is important that Enigmail is really integrated into the Thunderbird frontend.
As i have written it should be integrated in the assistant for email accounts and in the properties of the mail account itself.

When the Mozilla team will still ignore this necessity there is only the chance to make a branch like in the Tor project.
I have looked for the downloads of the Tor browser and there is no statistic on the homepage itself (Maybe i ask them for it and i find it is a good idea to ask to host a secure Thunderbird also).
But here are some counters:
1.107.505 at chip.de
692.382 + 181.863 at cnet.com
120.306 at computerbild.de
and much more

So there is MUCH INTEREST for security and privacy.
But it must be simple like the software bundle from Tor.
This is also not provided and hostet by Mozilla.

@Patrick Brunschwig: Do you see a chance to get a well integrated package of Thunderbird and Enigmail?
The question is not "is it possible". You can already today create your own Thunderbird installer with Enigmail builtin.

The only question is: what do Thunderbird folks want?

Comment 248

4 years ago
I think that the folk is more sensible about privacy and security now after Snowden.
So it is the perfect time now for a good new email solution.

But the folk is very lazy and don't want to think and alter habits.
Everything should happen "automatic" as possible.
So there must be a Thunderbird that must simply be installed/unpacked and started.
Then it is doing/asking what needed for the security/privacy like in the Tor browser.

That's i am talking about.
(In reply to Patrick Brunschwig from comment #247)
> The question is not "is it possible". You can already today create your own
> Thunderbird installer with Enigmail builtin.
> 
> The only question is: what do Thunderbird folks want?

Well, this bug is in the top three by votes, so clearly the Thunderbird community is interested to see it happen. I think the resolution of this bug boils down to whether one of the long-term Thunderbird developers (not me) is interested in seeing this happen and does some work on it in collaboration with the release guys, but this bug appears to be invisible at the moment (too hard or too historically charged or whatever). 

Patrick, in this bug and the one on Sourceforge you mention rejections, but the why, when and who is a bit cloudy to me. Not sure if you would like to expand on this, but perhaps you can help by identifying who would be needed to be convinced for this to see the light of day.

The installer route may be worth considering. See also Comment 203 from 2003. Note though that the official Thunderbird installer would have to be modified because this bug is about inclusion in the Thunderbird release.

If the integration is too much effort or comes with resistance, modifying 

 a) the installer to install the latest Enigmail extension from addons.mozilla.org (ala Web Developer extension and Feedback), or 
 b) the welcome/setup wizard to include an option/link to install Enigmail (open website, or install directly and proceed to the Enigmail setup wizard),

could be a stepping stone solution?
(In reply to Patrick Brunschwig from comment #245)
> The question is not whether we (the Enigmail developers) want to integrate
> Enigmail into Thunderbird. In the past, all our requests or proposals to
> integrate Enigmail were rejected.

As you may know, recently at the Thunderbird Summit we discussed a plan for Lightning, and the decision was to integrate it as a shipped but disabled-by-default addon with the next version of Thunderbird. The case is weaker for Enigmail, but the precedent at least exists. (It remains to be seen if the Lightning folks can get that integration done in time, however).

I believe that some of the earlier resistance may have come from the fact that, previously, the core code was maintained by staff, and they did not feel they had the capacity to take on additional new code. But now all of the Thunderbird code is maintained by volunteers, so that argument is weaker.

Still, I am not convinced that there is a strong case for implementation of Enigmail into the core code, either directly or as a shipped addon. The main issues are 1) is there a community of people who understand and can maintain the code? 2) Are there distinct advantages that would be gained that an addon does not have? 3) Is this something that a significant number of our users would want?

Although perhaps unfair to compare this with Enigmail, in the existing case of the integrated S/MIME code, this is not an area where there is a lot of activity by existing active contributors. The existing S/MIME code is mostly unowned, and seems to only have one or two patches per year that are not forced patches to stop breakages. This is the type of situation that we would fear in adding an extension to core, either directly or as a shipped extension.

In summary, this is a new era for Thunderbird, and we are open to a lot of things that perhaps seemed like settled issues in the past. That does not mean that incorporation of Enigmail is a slamdunk, but the issues are more practical than philosophical. I don't think there is much opposition to the idea that, ideally, Thunderbird should have robust security features, which would included PGP support.
(In reply to Patrick Brunschwig from comment #245)
> The question is not whether we (the Enigmail developers) want to integrate
> Enigmail into Thunderbird. In the past, all our requests or proposals to
> integrate Enigmail were rejected.

My understanding is that the Enigmail license is unacceptable, because it ultimately relies on GPL code (GnuPG), and this proved one of the major stumbling blocks. In the medium term, I consider PGP support in-scope for JSMime, and it would probably be a fairly simple matter to, say, lift WhiteOut's JS implementation.

The other major stumbling block has been the desire for good security UI, although, quite frankly, this is still more or less an open research problem, and I don't think we have the resources to solve it.

My recollection of the current implementation is perhaps out-of-date, but so long as it relies on an external program for encryption/decryption, I do not think Enigmail is suitable for integration into Thunderbird.
Another note:

There is no doubt that integrated PGP support would be a useful feature for Thunderbird. However, we are challenged in the amount of resources we have available, and it is not clear that integrating PGP support is the best use of those resources: even if it were as simple as integrating Enigmail, it would still require at least four different reviews that might be better spent on other tasks, like properly supporting EAI, especially since there is already a well-baked add-on that does it, and setting up PGP is no less complicated than installing an add-on.

As Kent says, at this point, the discussion to be had is not philosophical but practical.

Comment 253

4 years ago
Thank you that you pick up the discussion!

> Well, this bug is in the top three by votes, so clearly the Thunderbird community is interested to see it happen.

That's it - not less or more.
Why do you need more?

> 1) is there a community of people who understand and can maintain the code?

Of course, because this is an important opensource project.
But if the discussion will focus on copyright and not on the functionality, it will end like openoffice. ;-)

I am not an expert of copyright, but i think there will be an solution with enigmail, because the main persons of this project are already involved in the discussion and want the integration of this functionality for years!

> 2) Are there distinct advantages that would be gained that an addon does not have?

My hope was i could explain the difference.
I will try it again more concrete.

Yesterday i could test the enigmail plugin and found out that it works fine!
It does everything that's needed including a comfortable automated encrypting/decrypting of the mails.

BUT i must know what i have to do to use it, specially the generating and maintaining of the keys.
It can be used only by advanced users who already have undestand the complete encryption process.

That's to complicated for the novice or standard user!
Folks is used to have an easy approach to complicated stuff like an encryption process.
You don't have to do complicated things to use https even.

So it is not sufficient to ship the enigmail plugin in Thunderbird only.
There will be no advantage for the users, because they still don't know what to do to get the mails encrypted.
The users that are advanced enough to use enigmail will know how to install this plugin.

The goal is to get the right integration of encryption into Thunderbird.
This can only be done like i have written https://bugzilla.mozilla.org/show_bug.cgi?id=22687#c239

Additional my comparison to the Tor project: 
With the right knowledge it is possible to configure an own Tor browser, but the normal user is not able to do it.
So it is important that there is an instant solution a novice and standard user can use directly.

> 3) Is this something that a significant number of our users would want?

Of course - just look at the statistics of the Tor project.
https://metrics.torproject.org/networksize.html?graph=networksize&start=2010-10-09&end=2015-01-07
http://geography.oii.ox.ac.uk/?page=torproject
(In reply to Joshua Cranmer [:jcranmer] from comment #251) 
> My understanding is that the Enigmail license is unacceptable, because it
> ultimately relies on GPL code (GnuPG), and this proved one of the major
> stumbling blocks. In the medium term, I consider PGP support in-scope for
> JSMime, and it would probably be a fairly simple matter to, say, lift
> WhiteOut's JS implementation.

I don't think that the license of Enigmail is an issue. Yes, Enigmail interfaces with an external component that is GPL licensed, but Enigmail itself is MPL 1.1 (and we could certainly change it to MPL 2, if that would be required). As GnuPG is not part of Enigmail this is perfectly valid.

However, and I agree that this is an issue: GnuPG cannot not be part of Thunderbird distributions due to license issues. We would always have to download it from an external source. Thus a change to a MPL-compatible JS-based OpenPGP implementation would certainly help.
(In reply to Kent James (:rkent) from comment #250)
> Still, I am not convinced that there is a strong case for implementation of
> Enigmail into the core code, either directly or as a shipped addon. The main
> issues are 1) is there a community of people who understand and can maintain
> the code? 2) Are there distinct advantages that would be gained that an
> addon does not have? 3) Is this something that a significant number of our
> users would want?

I would add (and as jcranmer has hinted): 4) Are we able to give users a good UI experience - definitely as part of an integrated UI with S/MIME (it would make no sense for Thunderbird to have two entirely separate crypto UIs) and then to provide a UI whose usability matched that of the rest of the application. Enigmail is good, working software, and I use it, but at the moment (perhaps due to the inherent nature of the problem), I wouldn't say its UI is nearly as user-friendly as the rest of Thunderbird's.

Gerv

Comment 256

4 years ago
> ... it would make no sense for Thunderbird to have two entirely separate crypto UIs) and then to provide a UI whose usability matched that of the rest of the application.

We are talking here about a secure end-to-end encryption and not only about a secure mail transfer.
1. You have no control over the encryption of the email server your mail is transported.
2. The mail will not be stored in a secure encrypted way.

Only GnuPG gives you the full control over an end-to-end mail security and your keys!

For a save mail transport and privacy of the mail meta data projects like https://darkmail.info will cover this problem in the future.
There is a branch named VOLCANO to cover the specials need for DIME already:
https://www.youtube.com/watch?feature=player_detailpage&v=TWzvXaxR6us#t=1385

Comment 257

4 years ago
(In reply to Patrick Brunschwig from comment #254)
> I don't think that the license of Enigmail is an issue. Yes, Enigmail
> interfaces with an external component that is GPL licensed, but Enigmail
> itself is MPL 1.1 (and we could certainly change it to MPL 2, if that would
> be required). As GnuPG is not part of Enigmail this is perfectly valid.

Of course, Enigmail just runs gpg in pipe (or something of that kind), right?
There is absolutely nothing in GPL to prevent that (even if we were talking
about completely proprietary software like Outlook). Input and output of any
program are just yours and there is no license attached to them.

> However, and I agree that this is an issue: GnuPG cannot not be part of
> Thunderbird distributions due to license issues. We would always have to
> download it from an external source. Thus a change to a MPL-compatible
> JS-based OpenPGP implementation would certainly help.

Ask your lawyers but this is nonsense, IMHO (I used to be a lawyer, but not
anymore and of course my experience is limited to just one non-US jurisdiction,
so don't consider this as a legal advice). You can distribute on one disk (so to
speak, one zipfile this time more likely) anything you want. Linux distributions
CDs contain thousands of programs of all sorts (including some of them including
completely proprietary software like Flash player).

GPL viral-nature gets into play ONLY when you use some code from the GPL-covered
program in your program, or when you link to GPL (not LGPL) covered library.
None of these matter here right, because AFAIK Enigmail just runs gpg via pipe,
right?
GNU GPL only propagates to other projects if it is linked, or, in the strictest interpretation, if it is required for the functionality. Because you can also use Thunderbird without GnuPG, there is a good case for not requiring GPL for the integrated product. You can not use Enigmail without GnuPG, so if you distribute them together the duo has to be GPL-licensed. IANAL.

:gerv, :jcranmer: What do you think about my suggestion of integration into the installation and setup dialog, i.e. an official endorsement of Enigmail by Thunderbird for users who want it?

If resources is the only problem, then this is an important message you should convey, because then the status of this bug is: Someone who cares enough should become an experienced and trusted Thunderbird developer, and then start thinking about implementation. OTOH perhaps it is better to start with UI mockups (could be a student project)?
I would need to take advice on whether bundling GnuPG and Thunderbird together in a single installer would violate either the letter or spirit of the GPL. 

A post-install extra download would not be a problem. But certainly for Linux, it's better for users to get GnuPG from their package manager.

Johannes: that's not my decision.

Gerv

Comment 260

4 years ago
> A post-install extra download would not be a problem. But certainly for Linux, it's better for users to get GnuPG from their package manager.

A post-install would be a good solution for Windows user.
But it seems to be no problem to ship and use a GPL software together with another license.
http://www.gnu.org/licenses/gpl-faq#WhatIsCompatible

"For some licenses, the way in which the combination is made may affect whether they are compatible—for instance, they may allow linking two modules together, but not allow merging their code into one module.
If you just want to install two separate programs in the same system, it is not necessary that their licenses be compatible, because this does not combine them into a larger work."

For Linux it is absolutely no problem, because gnupg can be managed by the package dependencies.
I have checked my Debian system and there gnupg is always installed, because it is part of the package manager.

Comment 261

4 years ago
I think all future comments should refer to "OpenPGP", which is the term used in RFC 4880.  "PGP" (without the "Open") is a registered trademark owned by one developer of OpenPGP applications.  (This is NOT a criticism of past use of "PGP", which I used myself when I meant "OpenPGP".)
(In reply to Johannes Buchner from comment #258)
> 
> :gerv, :jcranmer: What do you think about my suggestion of integration into
> the installation and setup dialog, i.e. an official endorsement of Enigmail
> by Thunderbird for users who want it?
> 

In the long run, I would like to have Thunderbird increase visibility of addons, with certain addons being considers core addons that are promoted internally ("official endorsement" as you call it), as well as coming with some sort of expectation that they would be maintained. Certainly EnigMail would be a key addon that would benefit from that.

There are a variety of levels such addons could have. One such level, where it ceases to be an addon at all and is integrated into the product, is currently being pursed for a couple of addons for wildly different reasons, (the Extra Folder Columns addon and New Account Types). The next tier would be addons shipped with the product, and we are hoping to do that with Lightning soon. You could imagine another tier, where the addon is shown in the addons list as disabled, but is not actually downloaded until the user tries to enable it (this functionality does not yet exist in the addons backend) that would eliminate any doubt about GPL licensing. Then finally you would have the existing featured addons.

As a general direction, Thunderbird has to fight the battle of excessive, confusing user interface exposed to users who don't use a feature. I would like to see more core features moved to addons (for example junk mail processing) if possible, particularly if these could be shipped addons that could be easily turned on and off without searching.

Perhaps such addons could be promoted in the initial setup. I can imagine a box that shows "standard" addons, some enabled and some disabled by default, that could be shown during setup and configured. EnigMail is not the only addons of course I would include in that list.

So that is where I see us going. Right now we are limited more by getting the decision made on how to do such things, and get them integrated, rather than any real doubt about whether EnigMail would fit into such a scheme. Clearly EnigMail would be a first-class addon option.

Comment 263

4 years ago
> "PGP" (without the "Open") is a registered trademark owned by one developer of OpenPGP applications.

O.K. sed 's/PGP/OpenPGP/g'

I reckon this will not get a problem even.
https://philzimmermann.com/EN/essays/WhyIWrotePGP.html


Regarding the plugin-theme i think it doesn't matter for the user if it is a plugin or part of Thunderbird.
The only advantage of a plugin is that you can deinstall it and make Thunderbird smaller.
But systems with small resources maybe will not take Thunderbird as email client.

Please - the main thing here is a perfect user-friendly integration of the encryption problem.
I will not speak for other plugins, but enigmail should get integrated very good and i believe it makes no sense to exclude this functionality in the future again.

> As a general direction, Thunderbird has to fight the battle of excessive, confusing user interface exposed to users who don't use a feature.

This point is really important, specially to the possible options of OpenPGP.
From my point of view i always find it a perfect solution to have a general option "simple" or "expert".
Then the user can easily hide the things he must not care about.
For this, each setting needs a property expert to know when it should be visible only in expert view.
As example i would refer to VLC.
(In reply to lsmod from comment #253)
> Thank you that you pick up the discussion!

As has been said before, philosophical discussion is no longer an issue. The issue is entirely on practical matters.

(In reply to Matěj Cepl from comment #257)
> Ask your lawyers but this is nonsense, IMHO (I used to be a lawyer, but not
> anymore and of course my experience is limited to just one non-US
> jurisdiction,
> so don't consider this as a legal advice). You can distribute on one disk
> (so to
> speak, one zipfile this time more likely) anything you want. Linux
> distributions
> CDs contain thousands of programs of all sorts (including some of them
> including
> completely proprietary software like Flash player).

GPL has distribution requirements that would come into play. Nevertheless, since both the author of Enigmail and at least one possible reviewer agree that the GnuPG code is an issue with regards to integration, the point is moot.

(In reply to Johannes Buchner from comment #258)
> :gerv, :jcranmer: What do you think about my suggestion of integration into
> the installation and setup dialog, i.e. an official endorsement of Enigmail
> by Thunderbird for users who want it?

That is best discussed in a separate bug.

> If resources is the only problem, then this is an important message you
> should convey, because then the status of this bug is: Someone who cares
> enough should become an experienced and trusted Thunderbird developer, and
> then start thinking about implementation. OTOH perhaps it is better to start
> with UI mockups (could be a student project)?

The problem is that, realistically speaking, the task of developing good security UI is not the kind that is easily accessible to neophyte developers.

Comment 265

4 years ago
> That is best discussed in a separate bug.

Will you open it?

> The problem is that, realistically speaking, the task of developing good security UI is not the kind that is easily accessible to neophyte developers.

When you want i can offer some help to get an good UI?

1. I can evaluate the needs of novice users by an survey in an Thunderbird forum.

2. Maybe i get some help from Johannes and we can improve the plugin for a better usabilty.
   (Specially estimating the simple and expert points and create helping text to explain the options)
Comment hidden (advocacy)
Comment hidden (advocacy)
Comment hidden (advocacy)
Comment hidden (advocacy)

Comment 270

4 years ago
(In reply to Schindler from comment #269)

What's wrong with Enigmail?
https://www.enigmail.net/download/

Also, I was sad to read this:
http://www.thoughtcrime.org/blog/gpg-and-me/

Comment 271

4 years ago
Don't you think that everything has been already said in this thread?

You agreed that it is senseful to implement this feature and then nothing happens ...
Comment hidden (advocacy)

Comment 273

4 years ago
http://pep-project.org/2015-09/s1441611880 Enigmail and PeP joined efforts to solve the usability problem.
Also they reached out to Rkent in terms of financing the Thunderbird development.

I think the solution to this bug is nearer than you guys think.
Comment hidden (spam)

Comment 275

4 years ago
It seems we have new facts now - here is my conclusion:

The goal is to have a standard implementation of encryption in the good known email client Thunderbird.
So it makes no sense to make a branch under a new name.
The Thunderbird Team will not implement this for over 10 years, but will do it for money.

I (as user) would initiate a kickstarter project to organize the needed money.
Then we will see the real common interest.

To do this i need the amount of money for it from the Mozilla Team !?
At least the most programming work is already done, but it must be analyzed, integrated and rounded to have an optimal usability.

It should be more detailed, but i made already a list of features here:
https://bugzilla.mozilla.org/show_bug.cgi?id=22687#c239

When you are thinking on a price for this, then you should additional think for the price to implement DIME into Thunderbird.
I would define this as 2 steps - maybe it is possible to do both.
https://github.com/lavabit/
There is already a modified Thunderbird under the name Volcano.
I have no doubt that you have the full support from Ladar Levison for this.

Here you can see that this will be successfull.
https://www.kickstarter.com/projects/ladar/lavabits-dark-mail-initiative
(In reply to lsmod from comment #275)
> The goal is to have a standard implementation of encryption in the good
> known email client Thunderbird.

Make sure that you read https://blog.mozilla.org/thunderbird/2015/08/thunderbird-and-end-to-end-email-encryption-should-this-be-a-priority/ and the 75 comments there, plus the tens of comments in the equivalent tb-planning thread, to see recent activity on this topic. See particularly the summary response https://mail.mozilla.org/pipermail/tb-planning/2015-August/004011.html

Really the proper place to discuss this further is on the tb-planning thread, not this bug.

> The Thunderbird Team will not implement this for over 10 years, but will do
> it for money... I (as user) would initiate a kickstarter project to organize the needed
> money.

I don't think that a Kickstarter project is a good idea at the moment. There needs to be a long-term plan to maintain the code, and Kickstarter is not a good solution for that.

Please take any further discussion to tb-planning.
Comment hidden (spam)
Restrict Comments: true
Summary: PGP Plugin → PGP support

Updated

4 months ago
See Also: → 48374

Updated

4 months ago
See Also: → 332503

Updated

3 months ago
Blocks: 48374
See Also: 48374
You need to log in before you can comment on or make changes to this bug.