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

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.

Help wanted.

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

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.

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.

Bulk moving all MailNews Security bugs to new Security: General component. The previous Security component for MailNews will be deleted.

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.

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?

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

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.

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?

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.

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.

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.

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!

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.

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

(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.

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

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.

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

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.

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.

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?

/* -*- 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!

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

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.

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.

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.

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.

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);

I doubt this is still 'helpwanted'.

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.

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.

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.

> 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?

> 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?

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?

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.

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=.

> 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.

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.

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.

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?

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.

> 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.

> 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.

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?

> 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...

> 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...

> 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.

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?

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

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

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.

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.

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.

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.

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).

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?

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].

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.)

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.

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...

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.

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.

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.

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?

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...

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.

> 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.

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?

Just to comment I think this bug is part of RFC 2440 http://www.openpgp.org/ & RFC RFC 2440 http://www.ietf.org/rfc/rfc2440.txt http://www.gnupg.org/ http://www.pgpi.org/ http://web.mit.edu/network/pgp.html

Would Bug 48374 need to be fixed for this to work?

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

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.

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.

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.

Ouch, "NAI to Sell Off PGP Product Line" http://slashdot.org/article.pl?sid=01/10/12/0129228&mode=thread

How about using GPG instead then?

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."

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.

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* :)

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.)

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?

>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.

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?

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. =)

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.)

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).

Here's the RFC for MIME Security with OpenPGP (3156) http://www.ietf.org/rfc/rfc3156.txt

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. ***

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

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

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.

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).

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

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.

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.

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.

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.

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.

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

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

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 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?

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.

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. ***

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?

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.

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?

> 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?

> 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

(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?

[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.

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.

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.

(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 .

Hi. Any development? I suggest you to integrate Enigmail + gnupg into Thunderbird.

(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.

(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.

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.

!!!!!!!!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.

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

(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.)

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.

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.

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.

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.

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

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.

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.

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?

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.

> 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.

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.

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?

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.

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