Open Bug 1562737 Opened 4 years ago Updated 1 month ago

Allow body search in encrypted messages ("regular search", QFB, filters)


(MailNews Core :: Search, enhancement, P3)



(Not tracked)


(Reporter: jorgk-bmo, Unassigned)



Body search uses its own "mini MIME" parser to interpret a message stream:

We could smarten that up to detect application/pkcs7-mime parts and run them through decryption before processing them further. That might even be possible for application/pgp-encrypted parts.

Kai, what do you think?

P.S.: This has been on my mind for a while, but today I wasted hours searching for an e-mail and it turned out to be encrypted and the search didn't find it :-(

Flags: needinfo?(kaie)

This is a dupe of bug 188988. Thanks for your idea for a new approach to solve the problem.
I don't mind having that functionality. Decrypting "only for searching" is better than other suggested that had been made in the other bug. (I don't like the idea to store all bugs unencrypted, and I don't like the idea of a plaintext fulltext index for encrypted messages.) However, your search would probably be quite slow, and while searching, you might get prompts for the master password, or for GnuPG key passwords. We'd have to invent a way to skip all decryption attempts during the search, if the user cannot enter the correct password.

Flags: needinfo?(kaie)

I didn't know that bug. Yes, the search would be slow, but better slow than wrong. Sure, we need to skip cases were we can't decrypt.

So, are you aware of a handy interface to pass in the encrypted part and get it decrypted. I haven't dug through MIME yet.

Flags: needinfo?(kaie)

The decryption of S/MIME messages is triggered in mailnews/mime/src/mimecms.cpp.
We have a streaming decoder, see how the decoder_context object is used.

nsCOMPtr<nsICMSDecoder> decoder_context = do_CreateInstance(NS_CMSDECODER_CONTRACTID, &rv);

You initialize it with a callback function that will be called with decrypted content.

decoder_context->Start(content_callback, data);

Then you have to feed chunks of the encrypted input data into decoder_context->Update(encrypted_input), which will decrypt the chunks, and call content_callback(decrypted_content). When you're done with all input, call decoder_context->Finish(info_object). You can ignore the contents of the info_object for your purpose.

The implementation of content_callback can search for the needle, but doesn't need to do anything else with the haystack it's receiving. However, a single call to content_callback might contain only a subset of needle. So to be really certain, you'd have to search across boundaries of chunks. A possible solution is to grow a large buffer of all decrypted content, and delay the search until you have processed all input.

This will also help with S/MIME (CMS) messages that are signed-only (not encrypted), but uses the CMS opaque encoding, so a simple search through it doesn't work.

Flags: needinfo?(kaie)

OK, and for application/pgp-encrypted parts?

I haven't yet studied how PGP processing in Enigmail works.

It goes via the PGP Proxy. I tried to document it a bit once upon a time:

But there's most likely not a handy call like for S/MIME.

See Also: → 280588

(In reply to Kai Engert (:KaiE:) from comment #1)

This is a dupe of bug 188988. Thanks for your idea for a new approach to solve the problem.

Actually, no, that bug is for Gloda search which "should" already work, but doesn't.

See Also: → 188988
Summary: Allow body search in encrypted messages → Allow body search in encrypted messages ("regular search", QFB, filters)
Severity: normal → N/A
Priority: -- → P3
You need to log in before you can comment on or make changes to this bug.