[Rt-commit] rt branch, 4.2/skip-asc-keys, created. rt-4.2.10-223-g2aacd64

[Alex Vandiver]

The branch, 4.2/skip-asc-keys has been created
        at  2aacd649ed82b861d04cc5b861054106b2d8e97c (commit)

- Log -----------------------------------------------------------------
commit 2aacd649ed82b861d04cc5b861054106b2d8e97c
Author: Alex Vandiver <alexmv at bestpractical.com>
Date:   Wed Mar 25 18:41:17 2015 -0400

    Allow attachments that were only _guessed_ to be encrypted, to fail
    
    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.

diff --git a/lib/RT/Crypt.pm b/lib/RT/Crypt.pm
index cad86d2..89f4905 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 ddb91e4..b091019 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;

-----------------------------------------------------------------------