The 'btoa' command uses text-mode libc file I/O functions to write to the output. It calls the NSSBase64 functions to do base64 encoding. The NSSBase64 encoding functions use CRLF (\r\n) as line breaks. When \r\n is passed to the text-mode libc file output functions, we get - \r\n on Unix; - \r\r\n on Windows, neither of which is the correct line break for text files on that platform. We can fix this in either of two ways: 1. Change btoa.c to use binary-mode libc file I/O functions to write to the output. The output file will have \r\n line breaks on all platforms. 2. Change the NSSBase64 encoding functions in mozilla/security/nss/lib/util/nssb64e.c to use just \n as line breaks and let the text-mode libc file I/O functions in btoa.c translate \n to the correct native line breaks on that platform. Which method to use depends on whether we want to use \r\n or the platform native line break on all platforms.
Created attachment 16750 [details] [diff] [review] A patch to change btoa.c to use binary-mode libc file output.
I attached this patch first not because I think it's a better solution but because it is easier.
Ian, please let me know if this should be fixed in 3.2 or can be deferred. Thanks.
Target Milestone: --- → 3.2
According to RFC 1421, "To represent the encapsulated text of a PEM message, the encoding function's output is delimited into text lines (using local conventions)..." Thus, IMO the encoder should always use \n and not \r\n. This change will precipitate into many of the tools, as some use binary mode write (PR_Write).
Priority: P3 → P1
Ian, 1. "local conventions" surely implies "the conventions of the local system". For Unix, that's \n, for Macintosh that's \r, and for Windoze that's \r\n. So, why should the encoder always use \n? 2. Do we care about conformance to the old PEM RFCs?
It was my understanding that \n's will be converted to \r\n's on Windoze, and left alone on Unix, when using fwrite. The problem is that the encoder always produces \r\n's, which is fine if you always use binary mode, but problematic on Windoze if using ascii mode, since the \r\n's will become \r\r\n's. So there are two solutions: change all the tools to use binary mode I/O, or change the encoder. I took that line in the PEM spec to mean that the encoder is what should be changed. Personally, I think the output from the encoder should be suitable for ascii mode output, since users might not assume otherwise.
moving to future while we consider this more.
Target Milestone: 3.2 → Future
Changed the QA contact to Bishakha.
QA Contact: sonja.mirtitsch → bishakhabanerjee
QA Contact: bishakhabanerjee → jason.m.reid
Obviously not P1 in any sense.
Assignee: bugz → wtchang
Priority: P1 → P4
Target Milestone: Future → ---
You need to log in before you can comment on or make changes to this bug.