Okay I reread the RFC yet again :-) Literal Data packets of type text/unicode ('t' and 'u') have CR/LF EOLs not the ORIGINAL as I thought so I surrender and 
will change to just LF. I will submit another PR to fix master and change my pending PR for devel. 

However in looking at the implementation of literalDataPacket and its usage I believe there are issues with incorrect encoding and decoding of 
UTF-8. I don't believe the current implementation will correctly handle encryption and decryption of binary data. I will submit a PR for review 
that cleans up the encoding / decoding issues. 

----- Original Message -----

| From: "Robert B. Nelson" <robertn@the-nelsons.org>
| To: "openpgpjs/openpgpjs"
| <reply@reply.github.com>
| Cc: "openpgpjs/openpgpjs" <openpgpjs@noreply.github.com>
| Sent: Saturday, December 7, 2013 10:20:29 AM
| Subject: Re: [openpgpjs] Merge signature changes from master (#137)

| No my changes do no normalization of EOL, the APIs preserve the text with its
| original EOL. The only exception is clear signed text in which
| it is imposssible to know what the original EOL values were and so it uses
| canonical form. I believe the library shouldn't be arbitrarily munging
| the content of data it is processing, it should be up to the caller to do EOL
| translation if necessary based on its knowledge of the platform and
| usage of the data.

| ----- Original Message -----

| | From: "Thomas Oberndörfer" <notifications@github.com>
| 
| | To: "openpgpjs/openpgpjs" <openpgpjs@noreply.github.com>
| 
| | Cc: "Robert Nelson" <robertn@the-nelsons.org>
| 
| | Sent: Saturday, December 7, 2013 6:39:38 AM
| 
| | Subject: Re: [openpgpjs] Merge signature changes from master (#137)
| 

| | In src/packet/literal.js:
| 
| | >    /**
| 
| | >     * Get the byte sequence representing the literal packet data
| 
| | >     * @returns {String} A sequence of bytes
| 
| | >     */
| 
| | >    this.getBytes = function() {
| 
| | > -    var bytes = this.data;
| 
| | > -    switch (this.format) {
| 
| | > -      case 'utf8':
| 
| | > -        bytes = bytes.replace(/\n/g, '\r\n');
| 
| | > -        bytes = util.encode_utf8(bytes);
| 
| | > -        break;
| 
| | > -      case 'text':
| 
| | > -        bytes = bytes.replace(/\n/g, '\r\n');
| 
| | > -        break;
| 
| | > -    }
| 
| | > -    return bytes;
| 
| | > +    return this.format == 'utf8' ? util.encode_utf8(this.data) :
| | > this.data;
| 
| | >    }
| 
| | >
| 

| | End of line has always been a source of problems in the library. Your
| | changes
| | improve the situation,
| 
| | still I think we should discuss what is the normalized form of end of line
| | and should it be consistent for all text return values?
| 

| | With normalized form I mean not the canonical form \r\n that is used to
| | encode e.g. cleartext signed message,
| 
| | but the form of text that you expect as return value from
| | openpgp.decryptMessage, openpgp.decryptAndVerifyMessage,
| 
| | Message.getText and CleartextMessage.getText.
| 

| | My point is: I think it should be normalized and consistent, that is
| | independent of the internal encoding, these messages should
| 
| | return a normalized line ending. This is similar to unicode, I also would
| | expect that these messages return all UCS-2 (which is
| 
| | currently the case).
| 

| | Question is which normalization to use. You seem to prefer \r\n. I lean
| | towards \n as it's used in Chrome, Firefox and node.js
| 
| | and get's converted in IE.
| 

| | Currently return values are not consistent: CleartextMessage.getText always
| | returns \r\n, while after your changes above
| 
| | Message.getText gets not normalized and returns the internal end of line
| | encoding.
| 

| | —
| 
| | Reply to this email directly or view it on GitHub .
|