diff options
author | Alex Vandiver <alexmv@bestpractical.com> | 2015-03-26 01:41:17 +0300 |
---|---|---|
committer | Alex Vandiver <alexmv@bestpractical.com> | 2015-04-07 08:02:40 +0300 |
commit | 2aacd649ed82b861d04cc5b861054106b2d8e97c (patch) | |
tree | a70626cae428473d092975dd9fcb9f021ad5b4bb | |
parent | 1af864643155ed9794b106d0b3c0e106eff4e883 (diff) |
Allow attachments that were only _guessed_ to be encrypted, to fail4.2/skip-asc-keys
Files ending in ".asc" or ".pgp", unclaimed from RFC3156 multiparts or
unpaired with other attachments, were assumed to be encrypted
attachments. However, all the ".asc" or ".pgp" actually implies is
"ASCII-armored PGP data" or "binary PGP data", respectively. This
includes not only encrypted data, but also attached exported public
keys.
When RT attempts to "decrypt" an attached public key (which begins with
"BEGIN PGP PUBLIC KEY BLOCK", not "BEGIN PGP MESSAGE"), GPG responds:
gpg: decrypt_message failed: Unexpected error
..or, for gpg2:
gpg: decrypt_message failed: unexpected data
This results in the email sender receiving a "Error: bad encrypted data"
email, which is especially puzzling if their mail did not contain any
encrypted parts.
Content-type is insufficient to accurately distinguish between attached
public keys and attached encrypted data; mail clients often
indiscriminately mark both as "application/octet-stream". Determining
which is contained in the MIME part requires examining the contents of
the part -- which requires loading them into memory, which may be
prohivitive.
Instead, opportunistically attempt to parse such parts, marking them as
"Guessed", and allowing them to silently fail without generating a
confusing message to the end-user.
-rw-r--r-- | lib/RT/Crypt.pm | 2 | ||||
-rw-r--r-- | lib/RT/Crypt/GnuPG.pm | 6 |
2 files changed, 8 insertions, 0 deletions
diff --git a/lib/RT/Crypt.pm b/lib/RT/Crypt.pm index cad86d24fe..89f4905988 100644 --- a/lib/RT/Crypt.pm +++ b/lib/RT/Crypt.pm @@ -541,6 +541,8 @@ sub VerifyDecrypt { %args, Protocol => $protected->{'Protocol'}, Info => $protected ); + next if $res{skip}; + # Let the header be modified so continuations are handled my $modify = $res{status_on}->head->modify; $res{status_on}->head->modify(1); diff --git a/lib/RT/Crypt/GnuPG.pm b/lib/RT/Crypt/GnuPG.pm index ddb91e4f51..b091019618 100644 --- a/lib/RT/Crypt/GnuPG.pm +++ b/lib/RT/Crypt/GnuPG.pm @@ -850,6 +850,7 @@ sub FindScatteredParts { Type => 'encrypted', Format => 'Attachment', Data => $part, + Guess => 1, }; } @@ -1177,6 +1178,11 @@ sub _DecryptInlineBlock { # XXX: add argument to the function to control this check delete $res{'message'} if $res{'status'} =~ /DECRYPTION_OKAY/; + # Ignore various forms of "not actually PGP data" if we were merely + # optimistically guessing that this was encrypted data. + $res{skip} = 1 if $args{Guess} + and $res{'status'} =~ /(UNEXPECTED 0|NODATA [12])/; + return (undef, undef, %res) if $res{message}; seek $tmp_fh, 0, 0; |