| commit | 38fa2dab97180dc61a7b0582984f36ba6d8eb93c | |
| author | Jan Kundrát <jkt@kde.org> | |
| Mon, 21 May 2018 09:42:01 +0000 (21 11:42 +0200) | ||
| committer | Jan Kundrát <jkt@kde.org> | |
| Mon, 21 May 2018 09:45:10 +0000 (21 11:45 +0200) | ||
| tree | 8e75d746005cbcd7c4145c61d248dfa904042e98 | treesnapshot (tar.gz zip) |
| parent | 626b9fbd2cc4c40cce4a7aed50fa4a39c82625f9 | commitdiff |
crypto: EFAIL: clarify that we handle broken encrypted messages properly
If a message that is encrypted fails the decryption for some reason, gpg
might still provide us with its plaintext. That can happen when the MDC
(Modification Detection Code) indicates that it's been tampered with,
for example. As per upstream's recommendations, we've been always
ignoring the cleartext in that case.
Let's clarify that this is on purpose as a part of a defense-in-depth
approach. Our HTML renderer still would not request external entities
and therefore it won't leak the cleartext to the adversary.
Change-Id: Ic5b175a7d230ccdb99d74902782a01aa09339c14
If a message that is encrypted fails the decryption for some reason, gpg
might still provide us with its plaintext. That can happen when the MDC
(Modification Detection Code) indicates that it's been tampered with,
for example. As per upstream's recommendations, we've been always
ignoring the cleartext in that case.
Let's clarify that this is on purpose as a part of a defense-in-depth
approach. Our HTML renderer still would not request external entities
and therefore it won't leak the cleartext to the adversary.
Change-Id: Ic5b175a7d230ccdb99d74902782a01aa09339c14
| src/Cryptography/GpgMe++.cpp | diffblobblamehistory |