Open
Bug 56057
Opened 24 years ago
Updated 2 years ago
btoa generates wrong line breaks.
Categories
(NSS :: Tools, defect, P4)
Tracking
(Not tracked)
NEW
People
(Reporter: wtc, Unassigned)
Details
Attachments
(1 file)
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.
Reporter | ||
Comment 1•24 years ago
|
||
Reporter | ||
Comment 2•24 years ago
|
||
I attached this patch first not because I think it's a better solution but because it is easier.
Reporter | ||
Comment 3•24 years ago
|
||
Ian, please let me know if this should be fixed in 3.2 or can be deferred. Thanks.
Target Milestone: --- → 3.2
Comment 4•24 years ago
|
||
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
Comment 5•24 years ago
|
||
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?
Comment 6•24 years ago
|
||
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.
Comment 7•24 years ago
|
||
moving to future while we consider this more.
Target Milestone: 3.2 → Future
Reporter | ||
Comment 8•23 years ago
|
||
Changed the QA contact to Bishakha.
QA Contact: sonja.mirtitsch → bishakhabanerjee
Updated•20 years ago
|
QA Contact: bishakhabanerjee → jason.m.reid
Comment 9•19 years ago
|
||
Obviously not P1 in any sense.
Assignee: bugz → wtchang
Priority: P1 → P4
Target Milestone: Future → ---
Updated•19 years ago
|
QA Contact: jason.m.reid → tools
Comment 10•2 years ago
|
||
The bug assignee didn't login in Bugzilla in the last 7 months, so the assignee is being reset.
Assignee: wtc → nobody
Updated•2 years ago
|
Severity: normal → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•