---- Reported by firstname.lastname@example.org 2012-03-25 13:29:00 -0700 ----
Original Redmine bug id: 4919
Original URL: http://redmine.yorba.org/issues/4919
Searchable id: yorba-bug-4919
Original author: Christian Dywan
Geary should pick up configured GPG keys to decrypt messages and verify signed
messages. It should also allow choosing a GPG identity to associate with an
related to geary - 5130: Strip common message armor from previews (Fixed)
---- Additional Comments From email@example.com 2013-05-15 15:09:00 -0700 ----
Updated by Adam Dingle over 1 year ago
* **Priority** changed from _Normal_ to _High_
Yes - this would be great.
Updated by . . about 1 year ago
Any chance to get this into 0.3?
Updated by Jim Nelson about 1 year ago
* **Target version** set to _0.3.0_
It's certainly something we can consider for 0.3.
Updated by Eric Gregory about 1 year ago
A comment on our blog mentioned GPGME, an official API around GPG. A Google
search for "gpgme.vapi" came up with some leads. Here's the first result:
Updated by Jim Nelson 10 months ago
* **Category** set to _client_
* **Target version** changed from _0.3.0_ to _0.4.0_
This isn't going to happen for 0.3. Moving to 0.4.
Updated by Sandra Schlichting 8 months ago
Transparent encryption means that I will still be able to search in those
emails, right? Otherwise I don't think anyone would use it.
Updated by Jim Nelson 8 months ago
That's a good point. We should be able to search plaintext messages that have
been signed, but to do a full-text search of encrypted mail would me,
pragmatically, we would need to store the messages in the clear, which is
unwise. We should do more research here.
Updated by Adam Dingle 8 months ago
I for one have no problem with storing encrypted messages in the clear - we
could certainly make that an option. For me, the huge security/privacy hole in
email that's been gaping open since about 1980 is that nearly all messages
travel across the wire unencrypted, which means they can be easily read by my
IMAP provider, and also read by anyone on the pipeline between mail providers
(unless SSL is used at every step along the way). If we can solve that by
making GPG encryption the norm between any two parties who have it enabled,
that would be huge. For me, "transparent" means that the user doesn't even
notice it's there. If I'm worried about the security of data on my machine
itself, I can always store my mail on an encrypted partition, but in my mind
that's a separate problem which is possibly outside the scope of Geary.
Updated by Sandra Schlichting 8 months ago
I see some problems/challenges with GPG and email:
* If the sent and received are not searchable, then they for the users point of view doesn't exist
* With IMAP the emails are kept on the server, so using GPG just for transport only solves the problem, if you trust the IMAP provider.
* For the majority of email that people send will not be encrypted. So the problem arises when the user have to write this important and secret email. After writing it, I forget to click Encrypt/Sign. It pretty much always happens to me.
* Even if Geary detects that both sender and receiver uses Geary, that doesn't mean that they want to use GPG. E.g. if one of the parties want to read the email by webmail.
Implementation wise I see options:
* always keep plain text
* keep cipher text and ask for passphrase when searching (here also ask for decrypt all encountered. No option in Preferences would be needed.
* always encrypt the messages in Geary's database. Have to trust IMAP provider problem.
There are lots of papers on how to search in encrypted text. Just Google
"search encrypted text".
Updated by akabos @ 7 months ago
I can live without encryption at all. But unability to _sign_ messages
effectively blocks me from using Geary. So why not split this issue into two
parts? Implementation of GPG signing alone should be much easier task to begin
with but would allow people like me start using Geary sooner.
Updated by Jim Nelson 7 months ago
Sometimes when features are proposed we use a generalized "umbrella" ticket
that indicates our intentions. When we get ready to implement the feature,
we'll produce smaller tickets for each stage of the implementation.
If you think about it, this umbrella ticket has four sub-tickets: (1) encrypt
outgoing message, (2) decrypt incoming messages, (3) sign outgoing message,
(4) verify incoming signed message. We could generate all those tickets, but
until we begin work on this feature, this one ticket will work.
Updated by Jim Nelson 6 months ago
* **Target version** changed from _0.4.0_ to _0.5.0_
--- Bug imported by firstname.lastname@example.org 2013-11-21 20:20 UTC ---
This bug was previously known as _bug_ 4919 at http://redmine.yorba.org/show_bug.cgi?id=4919
Unknown milestone "unknown in product geary.
Setting to default milestone for this product, "---".
Setting qa contact to the default for this product.
This bug either had no qa contact or an invalid one.
Resolution set on an open status.