56057 - btoa generates wrong line breaks.

Status: NEW

(NSS :: Tools, defect, P4)

Description

[Wan-Teh Chang]

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.

Comment 1

[Wan-Teh Chang]

Attachment: A patch to change btoa.c to use binary-mode libc file output.

Comment 2

[Wan-Teh Chang]

I attached this patch first not because I
think it's a better solution but because it
is easier.

Comment 3

[Wan-Teh Chang]

Ian, please let me know if this should be fixed
in 3.2 or can be deferred.  Thanks.

Comment 4

[Ian McGreer]

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).

Comment 5

[Nelson Bolyard (seldom reads bugmail)]

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

[Ian McGreer]

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

[Ian McGreer]

moving to future while we consider this more.

Comment 8

[Wan-Teh Chang]

Changed the QA contact to Bishakha.

Comment 9

[Nelson Bolyard (seldom reads bugmail)]

Obviously not P1 in any sense.

Comment 10

[BugBot [:suhaib / :marco/ :calixte]]

The bug assignee didn't login in Bugzilla in the last 7 months, so the assignee is being reset.