[blocked on google] outgoing rich text signed pgp/mime message broken

[tomholub]

possibly caused by #3127 - at least it worked on last released version. That means we need a test for this. It only affects rich text, which is only allowed on firefox, but eventually we want to allow rich text with pgp/mime on chrome too.

To reproduce: 1) use firefox 2) using send button chevron inco switch to "Rich text" and disable "encrypt" so you have a signed + rich text message 3) add text, you can make some part bold with ctrl+b just to make sure, then attach an image 4) view the sent message using FlowCrypt 5) view the sent message using Thunderbird (I haven't tried this)

[tomholub]

Here is the message it produced: broken.txt Here is a working one: previous version.txt

[rrrooommmaaa]

broken.txt -- this is how it looks in gmail. says "matching signature" but gray border

in FlowCrypt "inbox":

So the error is that image is recognized as "plain file" in "inbox"?

[tomholub]

The error is that on my end, I'm actually seeing this in Gmail:

[tomholub]

It's interesting that it rendered correctly for you, but not for me. Tried on both Chrome and Firefox.

[tomholub]

I just noticed - you were looking at the message in the sent:folder. That one works for me too.

I'm looking at the received message, which is the one I exported.

Try to import the received message, then you should be able to see the problem.

[rrrooommmaaa]

@tomholub I see that the broken.txt file you attached has different delimeters as compared with Flowcrypt's "sent". So it is sort of "after processing by google", correct?

[tomholub]

Hm. This used to work. Can you please test sending out a message from a little older firefox addon? For example

https://s3-us-west-2.amazonaws.com/cryptup-release/firefox/cryptup-io-firefox-7.9.5.xpi or even older.

I want to make sure that it's not us that started sending messages a bit differently, causing this Gmail mechanism to get triggered. I remember writing the sending code in a very specific manner to avoid Gmail API malforming the message for pgp/mime signed messages, and I wonder if something in that code changed on our end.

[rrrooommmaaa]

@tomholub Of course, modified message can't be verified if it is edited (boundaries have changed). So it should be not parse error, but verification error. I'm setting up tests for original and modified message.

[tomholub]

I'm not so worried if it's parse or verification error.

I wonder if anything changed about how we encode the message, which in turn caused google to start changing the boundaries that it didn't before.

[rrrooommmaaa]

7.9.5 produced the same error. I compared "rich text from prev version signed" and original "refactor - signed rich" from "Sent" folder -- they are identical in structure.

The deformed message on arrival doesn't have multipart/signed, it is re-formatted as multipart/mixed (by Gmail API?) as per #3032

[tomholub]

Excellent, thank you. I'll report it to them.

[tomholub]

I reported this also at https://partnerissuetracker.corp.google.com/issues/171715824

[tomholub]

Thank you - unassigned - waiting for Google.

[tomholub]

For context this is what I reported

---

Me:

short description: Structure of PGP/MIME messages should be preserved when sending through Gmail API (users.messages.send)

This bug affects several large organizations who use encrypted email, including Google's strategic enterprise customer.

Steps to reproduce: 1) compose a pgp/mime encrypted message (pgp/mime signed works ok) 2) send it through Gmail API to another account (Gmail or otherwise) 3) open the message on the receiving end (not on sender's side) 4) message will be malformed as described below

The sent message had the following structure:

Content-Type: multipart/encrypted; protocol="application/pgp-encrypted"; boundary="----sinikael-?=_1-16031047614490.8483156050873946"

------sinikael-?=_1-16031047614490.8483156050873946
Content-Type: application/pgp-encrypted; name=
Content-Description: PGP/MIME version identification
Content-Disposition: attachment
X-Attachment-Id: f_uyeXnnnxBHMzPjkQpzUnKlwciCoyZB@flowcrypt
Content-Id: <f_uyeXnnnxBHMzPjkQpzUnKlwciCoyZB@flowcrypt>
Content-Transfer-Encoding: base64

------sinikael-?=_1-16031047614490.8483156050873946
Content-Type: application/octet-stream; name=encrypted.asc
Content-Description: OpenPGP encrypted message
Content-Disposition: inline; filename=encrypted.asc
X-Attachment-Id: f_AcohxKCOvwZLUPQEMgsUwfzMzfpfWS@flowcrypt
Content-Id: <f_AcohxKCOvwZLUPQEMgsUwfzMzfpfWS@flowcrypt>
Content-Transfer-Encoding: base64

<snip>
------sinikael-?=_1-16031047614490.8483156050873946
Content-Type: application/pgp-keys; name=0x8C826EA5BCD44F29.asc
Content-Disposition: attachment; filename=0x8C826EA5BCD44F29.asc
X-Attachment-Id: f_btAAVzsmZSFAgNRdjjBNYQJegGCNjB@flowcrypt
Content-Id: <f_btAAVzsmZSFAgNRdjjBNYQJegGCNjB@flowcrypt>
Content-Transfer-Encoding: base64

<snip>
------sinikael-?=_1-16031047614490.8483156050873946--

The following message was delivered and pulled on the receiving end:

Content-Type: multipart/mixed; boundary="000000000000e5587e05b203e91d"

--000000000000e5587e05b203e91d
Content-Type: text/plain; charset="UTF-8"

<snip>

--000000000000e5587e05b203e91d
Content-Type: application/pgp-encrypted; name=""
Content-Disposition: attachment
Content-Transfer-Encoding: base64
Content-ID: <f_uyeXnnnxBHMzPjkQpzUnKlwciCoyZB@flowcrypt>
X-Attachment-Id: f_uyeXnnnxBHMzPjkQpzUnKlwciCoyZB@flowcrypt

--000000000000e5587e05b203e91d
Content-Type: application/pgp-keys; name="0x8C826EA5BCD44F29.asc"
Content-Disposition: attachment; filename="0x8C826EA5BCD44F29.asc"
Content-Transfer-Encoding: base64
Content-ID: <f_btAAVzsmZSFAgNRdjjBNYQJegGCNjB@flowcrypt>
X-Attachment-Id: f_btAAVzsmZSFAgNRdjjBNYQJegGCNjB@flowcrypt

<snip>
--000000000000e5587e05b203e91d--

In summary, the following changes caused the incompatibility: 1) Content-Type: multipart/encrypted; protocol="application/pgp-encrypted"; changed to Content-Type: multipart/mixed; 2) attachment with Content-Type: application/octet-stream; name=encrypted.asc lost all headers and changed to Content-Type: text/plain; charset="UTF-8", also changed order 3) attachment with Content-Type: application/pgp-encrypted; name= lost headers, and changed order

Full messages attached.

The appropriate RFC is at https://tools.ietf.org/html/rfc3156#section-4

I'm available to provide more details if needed.

Cheers, Tom

---

Google:

Thank you for filing this issue. I forwarded it internally and it is being investigated now.

---

Me:

Thank you. In the last few days, we have noticed similar issue newly started happening also on pgp/mime signed messages that didn't happen before.

It's not clear at what point did this newly break - we first observed it on Nov 15.