Encrypt with multiple keys per recipient #3799
Conversation
…with-all-available-keys
| if (encryptionKeys.some(k => k.usableForEncryption)) { | ||
| return [{ email, keys: encryptionKeys.filter(k => k.usableForEncryption) }]; | ||
| } else { | ||
| return [{ email, keys: encryptionKeys }]; | ||
| } |
There was a problem hiding this comment.
This looks good, to preserve existing notification that user key has expired. I think this may be the last step in facilitating smooth public key rotations / expirations as well - the old key will naturally expire, and both will be used in the in-between period.
There was a problem hiding this comment.
Actually, this could cause a little bit of trouble: we have a mechanism to keep public keys fresh, but it works higher up in the stack and probably needs all of the keys to work properly.
I can't come up with exact scenario when it would cause user-noticeable issues, but there possibly are some.
Ideally, the storage method would be returning all public keys for that recipient, and this logic would happen somewhere in composer view code / one of its modules. But the point is that the composer should have a chance to update a newer version of an expired key, even if some other valid key is available.
As it is now, it appears maybe the updated version of the expired key would not be noticed. (actually, depending on implementation, maybe on WKD it would be noticed since we pull by email and get back an array - can process the whole array which is good. But when pulling from Attester by fingerprint, that maybe doesn't work so well, because we don't ha ve a chance to pull updated version of the expired key)
2 participants
This PR uses as many encryption keys as it can find per each recipient
close #3769
Tests (delete all except exactly one):
To be filled by reviewers
I have reviewed that this PR... (tick whichever items you personally focused on during this review):