feat: import Autocrypt-Gossip keys without checking the addresses - #8638
Conversation
b75ee18 to
0092e25
Compare
|
This is from @Hocuri comment at #8620 (comment) |
| @@ -555,8 +555,7 @@ impl MimeMessage { | |||
| // but only if the mail was correctly signed. Probably it's ok to not require | |||
| // encryption here, but let's follow the standard. | |||
There was a problem hiding this comment.
We can probably also drop this check.
There was a problem hiding this comment.
autocrypt/gossip and securejoin will need a concerted revisit at some point, but i'd ask for caution now going for "refactors" when they drop checks in this area. Tests still passing after removing checks does not mean much, if the checks were never covered by tests.
|
First check was introduced in deltachat/deltachat-core@80a3cad in C core. The second check was introduced in a3fe105 (PR #3849) with the comment "Non-standard, but anyway we can't update the cached peerstate here." which was replaced in 416131b (large squashed key-contacts introduction commit) with "Non-standard, might not be necessary to have this check here". |
hpk42
left a comment
hpk42
left a comment
There was a problem hiding this comment.
I was just sidenoting about "refactor" commit title, and that there is no test coverage. I am ok to merge this PR as is.
It is safe to import any keys into the keychain. Keys can anyway be imported from vCards and Autocrypt headers without any checks. These checks are from the time before we had key-contacts and maintained Autocrypt `peerstates` table.
link2xt
changed the title
0092e25 to
b287f7e
Compare
3 participants
It is safe to import any keys into the keychain.
Keys can anyway be imported from vCards
and Autocrypt headers without any checks.
These checks are from the time before we had key-contacts and maintained Autocrypt
peerstatestable.