-
-
Notifications
You must be signed in to change notification settings - Fork 125
feat: Remove mostly-unused SignUnencrypted option #8190
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Changes from all commits
36cb7b4
813302a
d770284
a4aa11a
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -7,6 +7,7 @@ use crate::{ | |
| chat, | ||
| chatlist::Chatlist, | ||
| constants::{self, Blocked, DC_DESIRED_TEXT_LEN, DC_ELLIPSIS}, | ||
| contact::Contact, | ||
| key, | ||
| message::{MessageState, MessengerMessage}, | ||
| receive_imf::receive_imf, | ||
|
|
@@ -2041,32 +2042,24 @@ async fn test_multiple_autocrypt_hdrs() -> Result<()> { | |
| Ok(()) | ||
| } | ||
|
|
||
| /// Tests that timestamp of signed but not encrypted message is protected. | ||
| /// Tests receiving a simple signed-unencrypted message | ||
| /// that was generated by an old version of Core that supported sending such messages. | ||
| #[tokio::test(flavor = "multi_thread", worker_threads = 2)] | ||
|
Collaborator
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Not sure we should just remove this test, this means that we don't test that signed "Date" is taken from signed-only messages sent by other MUAs anymore. I'd like to have such a message in
Collaborator
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. If an attacker wants to spoof the date, they can just remove the signature, because we don't process signed-only messages differently than unsigned messages. But I will restore the rest of the test, putting the message in |
||
| async fn test_protected_date() -> Result<()> { | ||
| async fn test_receive_signed_only() -> Result<()> { | ||
| let mut tcm = TestContextManager::new(); | ||
| let alice = &tcm.alice().await; | ||
| let bob = &tcm.bob().await; | ||
|
|
||
| alice.set_config(Config::SignUnencrypted, Some("1")).await?; | ||
| let imf_raw = include_bytes!("../../test-data/message/unencrypted_signed_simple.eml"); | ||
| let msg = receive_imf(bob, imf_raw, false).await?.unwrap(); | ||
| assert_eq!(msg.msg_ids.len(), 1); | ||
| let msg = Message::load_from_db(bob, msg.msg_ids[0]).await?; | ||
| assert_eq!(msg.get_text(), "Hello!"); | ||
| assert_eq!(msg.viewtype, Viewtype::Text); | ||
| assert_eq!(msg.get_timestamp(), 1615987853); | ||
|
|
||
| let alice_chat = alice.create_email_chat(bob).await; | ||
| let alice_msg_id = chat::send_text_msg(alice, alice_chat.id, "Hello!".to_string()).await?; | ||
| let alice_msg = Message::load_from_db(alice, alice_msg_id).await?; | ||
| assert_eq!(alice_msg.get_showpadlock(), false); | ||
|
|
||
| let mut sent_msg = alice.pop_sent_msg().await; | ||
| sent_msg.payload = sent_msg.payload.replacen( | ||
| "Date:", | ||
| "Date: Wed, 17 Mar 2021 14:30:53 +0100 (CET)\r\nX-Not-Date:", | ||
| 1, | ||
| ); | ||
| let bob_msg = bob.recv_msg(&sent_msg).await; | ||
| assert_eq!(alice_msg.get_text(), bob_msg.get_text()); | ||
| let alice_contact = Contact::get_by_id(bob, msg.from_id).await.unwrap(); | ||
| assert_eq!(alice_contact.is_key_contact(), false); | ||
|
|
||
| // Timestamp that the sender has put into the message | ||
| // should always be displayed as is on the receiver. | ||
| assert_eq!(alice_msg.get_timestamp(), bob_msg.get_timestamp()); | ||
| Ok(()) | ||
| } | ||
|
|
||
|
|
||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This means that we don't even look at signed-only headers anymore. I'd split this PR into two because
SignUnencryptedand support for receiving signed-only messages are separate things.SignUnencryptedcan definitely be removedUh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
looking at signed-only is questionable as well. see k-9 blog eg.
from a high-level view, questionable, in general, and in special with our focus on chatmail, and not focusing on pgp specials. not only maintainance and impact, also the continuous discussions these special cases raise all the time are questionable already :)
Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If you're talking about https://k9mail.app/2016/11/24/OpenPGP-Considerations-Part-I and part II as well, i've read already. But everyone has different opinion on this topic, you can ask dkg for example.
We can remove signature checks for signed-only emails (btw, not removed in this PR) because we don't display them in any special way, but not parsing headers in all kinds of messages looks strange.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We should at least make sure we don't break parsing of
multipart/signedmessages so we don't end up with the mail being received as a file or something like that if we receive such signed-only message.I'd just keep this code to unwrap the message early, but remove all the comments like "Currently we do not sign unencrypted messages by default.". We are not going to start signing anything with multipart/signed, even thunderbird is now working on switching to https://datatracker.ietf.org/doc/draft-ietf-mailmaint-unobtrusive-signatures/
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As for whether to parse protected headers or not, in signed messages they are duplicating the unprotected headers anyway, so it does not matter which one to use, if we don't process signed-only messages differently then can as well use unprotected headers because it is anyway possible to just remove the signature and modify headers. Whatever is simpler to implement, as long as we have some test that incoming multipart/signed messages are displayed normally the same way as unencrypted, the whole code block can be removed as well if mimeparser handles it later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Being compatible with every imaginable MUA implementation doing weird stuff is a non-goal. And there are definitely many MUA implementations out there that are not able to process inner headers in a signed mime part, so, if a MUA doesn't duplicate headers into the outer part then they will need to live with incompatibilities.
I restored part of the tests, renaming it to
test_receive_signed_only(). It passes fine without any further adaptions to the code.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In addition, we already have
test_thunderbird_autocrypt_unencrypted(), which tests receivingthunderbird_signed_unencrypted.emlThere was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Where is the code that does these checks? I agree, would be great to be able to remove them, too!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we are the only client that produces RFC 9788 messages. Still waiting for Thunderbird to implement it, and there work is focused on https://datatracker.ietf.org/doc/draft-ietf-mailmaint-unobtrusive-signatures/ (see first bugzilla issue), likely by the time RFC 9788 is implemented multipart/signed signatures will be even less interesting:
Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So we're going to add one more such implementation... EDIT: Ok, after reading a bit https://datatracker.ietf.org/doc/draft-ietf-mailmaint-unobtrusive-signatures/ i agree that support for "multipart/signed" may be removed.
Maybe just parsing headers in all parts recursively (w/o any additional handling of "multipart/signed") is better.
grep validate_detached_signature