144621 - Components can add c-M to prefs, prefs parser cannot handle

Status: RESOLVED DUPLICATE of bug 143459

(Core :: Preferences: Backend, defect)

Description

[Nathan Neulinger]

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0+) Gecko/20020503
BuildID:    2002050321

My wife accidentally created a dir for camera pics named "2002-05-14^M". When
she emailed a pic from this directory in mozilla, the mail component put the
following line in prefs.js

user_pref("mail.compose.attach.dir", "/users/nneul/album/ebay/2002-05-14^M");

This results in the:

line 169: SyntaxError: unterminated string literal.
user_pref("mail.compose.attach.dir", "/users/nneul/album/ebay/2002-05-14
An error occurred reading the startup configuration file.  Please contact your a
dministrator.

Prefs parser appears unable to handle embedded c-M's. Either that needs fixed (I
presume it's a side-effect of win32 compat) to handle it, or the mail component
should be fixed to not pass in that type of reference. (I wonder if there are
any JS or similar remote exploits related to c-M injection in the config file?)

Reproducible: Always
Steps to Reproduce:
1. Create dir with ^M in name
2. Send as email attachment
3 [details] [diff] [review]. Exit and restart mozilla

Actual Results:  Complains about unparseable config file

Expected Results:  Should ignore ^M or not generate it.

Comment 1

[R.K.Aa.]

related to bug 127656?

Comment 2

[Nathan Neulinger]

Looks like it may be... Presuming that the prefs parser is using the full
javascript engine and not just a small subset. I've added that bug as a
dependency, if someone more familiar with the components thinks my report should
be closed as dup, thats ok too.

Then again, this bug might be more relating to the pref that is generated by the
mail component (either/both should probably be fixed).

Comment 3

[Phil Schwartau]

I think they are different problems. Here, we are getting the error
"unterminated string literal" because of the Mac line ending ^M
at the end of a string, no matter how long the string is.

In bug 127656?, the problem occurs specifically at positions 255-256...
(on the sequence: backslash followed by a literal line-break).

Comment 4

[Brian Nesse (gone)]

Actually I believe it is more likely a dupe of bug 143459. Marking as such.

*** This bug has been marked as a duplicate of 143459 ***