deltachat-core-rust
deltachat-core-rust copied to clipboard
deltachat
Deltachat Autocrypt Setup Message attachment mixes different line endings
-
Android version: 7.0
-
Device: Samsung Galaxy Tab S2
-
Delta Chat version: 1.14.5
-
Expected behavior: The attachment to the Autocrypt Setup Message that contains the private key should use the same ending for each of its lines, preferably CR-LF.
-
Actual behavior: The -----BEGIN PGP MESSAGE---- and Passphrase-Format: header lines end with CR-LF; while the Passphrase-Begin: line, the blank line following it, and the base64 encoded lines end with LF only. Here's part of the attachment represented as a Java string using \r and \n to represent CR and LF respectively.
"<!DOCTYPE html>\r\n" + "<html>\r\n" + " <head>\r\n" + " <title>Autocrypt Setup Message</title>\r\n" + " </head>\r\n" + " <body>\r\n" + " <h1>Autocrypt Setup Message</h1>\r\n" + " <p>This is the Autocrypt Setup Message used to transfer your " + "end-to-end setup between clients.<br><br>To decrypt and use your " + "setup, open the message in an Autocrypt-compliant client and enter " + "the setup code presented on the generating device.</p>\r\n" + " <pre>\r\n" + "-----BEGIN PGP MESSAGE-----\r\n" + "Passphrase-Format: numeric9x4\r\n" + "Passphrase-Begin: 07\n" + "\n" + "wx4EBwMIzINv/m9n1CPg3HZUFIlELyVWRb6K5KE6sufSwmYBe6bLVvxnnGwOKxT0\n" + "ePc6V95IBYQavbYFtf33FFDncD8bSS8DkK3Pq4WVoKIKECQerYoRu964pFcGw76Y\n" + "U2B8r5I8GWaRacWsyjsWRfLEJRQgK5ekv4epPtVq+y3zGVaViDh2HV1xP9+4emCN\n" + ... -
Steps to reproduce the problem: Use Delta Chat to create an Autocrypt Setup Message, open it with an email client, save the attachment to a file, use a hex dump program to display the file.
Comments:
This was discovered when using the Java library BouncyCastle on Debian to decrypt the setup message attachment. (GnuPG on Debian processes the same file OK.)
It could be argued that the software analyzing the data should tolerate mixed line endings, but this is complicated by the fact that OpenPGP uses a blank line (i.e. two consecutive EOLs) to mark the end of the headers and the start of the Base64 data.
If the only types of line endings were LF (e.g. 'nix) and CR-LF (e.g. Windows) it would be possible to program around mixed line endings by discarding all CRs. Unfortunately some systems, notably old (< OSX) Macs use CR alone as a line ending. So if a header line ends CR-LF and the goal is to accept any mixture of line endings, there is a fundamental ambiguity (is there a blank line or not?) that can only be resolved by more complex analysis of the data.
thanks for filing the issue, @JackDca
i moved the issue to deltachat-core-rust as there is not much android can do about it (deltachat-android is only about the UI)
the issue in BouncyCastle: https://github.com/bcgit/bc-java/issues/1056
@JackDca Thank you for filing the issue. You have used version 1.14.5, which is quite old. Is that behavior valid for the current release of Delta Chat (version 1.22.1) for Android, too?
Thanks for pointing out the old version!
Just installed version 1.22.1 from F-Droid on my tablet and generated a new Autocrypt setup message. Yes, it still mixes line endings. Here's a snippet as a Java string:
...
"setup, open the message in an Autocrypt-compliant client and enter " +
"the setup code presented on the generating device.</p>\r\n" +
" <pre>\r\n" +
"-----BEGIN PGP MESSAGE-----\r\n" +
"Passphrase-Format: numeric9x4\r\n" +
"Passphrase-Begin: 30\n" +
"\n" +
"wx4EBwMIPvEj4MfYAe3gXOYUMfNMndIj31aF4M4Wm1HSwmYBqPbgJNy+G15hFD0h\n" +
"3YU1qXqhMhUlo6uIHX02B8qPg0FWerC63mYQ8uqHfJjV/MHGxvaS7iKNtWL1ZZ9F\n" +
"7WFPMQgLGfRWwfHddZY6Oz9XpCKIdDMq+jKvZKa+k272S7ko5lPB1/tjUlyYSSQ7\n" +
...
I also cross-checked the above version by opening the saved file in hexdump.
