[Kde-pim] [Differential] [Commented On] D1964: Fix opening attachments in Opaque S/MIME encrypted messages

[dvratil (Daniel Vrátil)]

dvratil added a comment.


  So, the problem here is the following. Upon decrypting the message we end up with the current "tree" of parts:
  
    application/pkcs7-mime; smime-type: "enveloped-data"
    application/pkcs7-mime; smime-type: "signed-data"
       multipart/mixed
          text/plain
          application/octet-stream; content-disposition: attachment
  
  and the NodeHelper::mExtraContents table is like this:
  
    application/pkcs7-mime; smime-type: "enveloped-data" => [ application/pks-7-mime; smime-type: "signed-data" ]
    application/pkcs7-mime; smime-type: "signed-data" => [ multipart/mixed ]
  
  The problem here is that although mExtraContents indicates relation between the `signed-data` and `enveloped-data`, in reality the `signed-data` part is not a child of the `enveloped-data` message, although it should be (IMO), because the `signed-data` message is the content of the `enveloped-data` message, similar to `multipart/mixed` being the content of `signed-data`.
  
  The fact that this relationship is not present is visible on the URL of the attachment part:
  
    attachment:0:0::2?place=body
  
  Notice the double colon? That's `NodeHelper::persistentIndex()` failing to find the position of `signed-data` within its parent - because it has none!
  
  The problem is that `NodeHelper::persistentIndex()` is recursive only within the KMime::Content tree hierarchy, but it is not recursive in the terms of mExtraContents relationships.
  
  There are IMO two possible ways to fix this:
  
  1. Make `signed-data` a child of the original `enveloped-data` part.
  
  This is what I tried to do in my initial patch. The problem is that when the signature is being verified we no longer have the parent `enveloped-data` part available in pointers and such, and it happens in a code that is too generic to be the right place for this. Possibly larger change would be required to make this work
  
  2. Make `NodeHelper::persistentIndex()` smarter.
  
  The idea is to support recursive relation lookup through both `KMime::Content::parent()` as well as the mExtraContents table, using special prefix for the indexes in mExtraContents. As an example, the URL of the attachment with approach would be something like
  
    attachment:0:0:e0:2?place=body
  
  See the "e0"? That indicates that the part is not first child `enveloped-data`, but is the first element in `mExtraContents[enveloped-data-node]`.

REPOSITORY
  rMESSAGELIB PIM: Message Library

REVISION DETAIL
  https://phabricator.kde.org/D1964

EMAIL PREFERENCES
  https://phabricator.kde.org/settings/panel/emailpreferences/

To: dvratil, knauss
Cc: kde-pim, dvasin, winterz, smartins, vkrause, mlaurent, knauss, dvratil
_______________________________________________
KDE PIM mailing list kde-pim at kde.org
https://mail.kde.org/mailman/listinfo/kde-pim
KDE PIM home page at http://pim.kde.org/