Closed Bug 559782 Opened 15 years ago Closed 11 years ago

Obscure value not applied to lock files (.cfg)

Categories

(Thunderbird :: Preferences, defect)

All
Linux
defect
Not set
minor

Tracking

(Not tracked)

RESOLVED INVALID

People

(Reporter: martin.jungowski, Unassigned)

Details

User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); de; rv:1.9.2) Gecko/20100115 Firefox/3.6 Build Identifier: Thunderbird 2.0.0.24, Thunderbird 3.0.4 Creating .CFG files to lock down certain Thunderbird settings works only if one does NOT apply a ROT13 byte shift to the file, even though it is necessary according to the settings in greprefs/all.js: martin/mdesktop$ cat /opt/thunderbird/greprefs/all.js | grep obscure pref("general.config.obscure_value", 13); // for MCD .cfg files If I do apply the byteshift the settings in the file do not get applied. If I do not apply the byteshift they do get applied and the settings properly locked. Reproducible: Always Steps to Reproduce: 1. Create a .txt file to lock down Thunderbird settings 2. Apply a ROT13 byte shift to create a .cfg file (online or moz-byteshift.pl) 3. Modify greprefs/all.js to include the newly created .cfg file Actual Results: A ROT13 rotated .cfg file does not get read properly, the settings are neither applied nor locked. Applying a byte shift of 0 (aka not rotating at all) results in the file getting read and the settings getting properly applied and locked. Expected Results: The rotated file should get read instead. It works great in Firefox but not in Thunderbird. We use both, Thunderbird 3.0.4 and 2.0.0.24 and it fails to work with both versions.
Jehan thoughts are comments ?
I don't use anymore ROT13 ! it's a very old way to use autoconfig, why do you want to "code" your conf file ? I did used it at the begining when I was'nt aware that we could remove it but since I read : http://mit.edu/~firefox/www/maintainers/autoconfig.html "The general.config.obscure_value preference specifies how the configuration file is obscured. Firefox expects that each byte in the file will be rotated by the specified value. The default value is 13. If this value is left unchanged, then the configuration file must be encoded as ROT13. Autoconfig will fail if the cfg file is not encoded as specified by this preference. A value of 0 indicates that the file is unencoded-- i.e. it is unobscured plain text. It is recommended that you set this value to 0. (This will allow you to skip the encoding step in part 3.)" Then I kept using : pref("general.config.obscure_value", 0); // for MCD .cfg files Anyway, if you really want to code the file, did you applied the byteshift on your .cfg file while using 13 as oscure value ? # To encode: moz-byteshift.pl -s 13 <firefox.cfg.txt >firefox.cfg
Of course I did. The thing is: the obscure value of 13 is in both all.js files - Firefox and Thunderbird. However Thunderbird does not know how to read a rotated CFG file while Firefox does. In return, Firefox does not know how to read a CFG file that has NOT been rotated whereas Thunderbird does. What I'm saying is this: even though Thunderbird is preconfigured with an obscure value of 13 it doesn't know how to read properly rotated files but only unrotated files.
Oh, what I forgot: if ROT13 is a very old way for Autoconfig then why is it still required by Firefox 3.6 and, at least in theory, also by Thunderbird 3.0.4?
Also: I never changed that obscure value! It's set to 13 by default for both Firefox 3.6 and Thunderbird 3.0.4!
Component: Preferences → General
Product: Thunderbird → Core
QA Contact: preferences → general
you are right, as I always bindly added pref("general.config.obscure_value", 0); at the end of all.js ... I did'nt noticed that there was an "obscure_value, 13" set in there ! I supose that adding the line a the end of the file overlaoded that value . Well, I haven't test with byteshift, but if it doesn't work since recently , it's probably a bug . Any now and then, that autoconfig feature is broken by updates ... recently I cannot use anymore the displayerror() function to debug autoconfig :-( https://bugzilla.mozilla.org/show_bug.cgi?id=502597 Hope some of the developpers could help us.
(In reply to comment #3) > Of course I did. > > The thing is: the obscure value of 13 is in both all.js files - Firefox and > Thunderbird. That's true, but that isn't Thunderbird's default. Thunderbird's obscure value is set in all-thunderbird.js and is set to 0 (iirc config files are read in reverse alphabetical order or something like that). So Thunderbird's default obscure value is zero. So if you want to use an obscure value of 13 then you need to change the value in all-thunderbird.js or provide another method of changing it.
That's interesting... and it leaves me wondering why the obscure value is set in both config files by default and why Firefox reads its value from ./greprefs/all.js while Thunderbird reads its value from ./defaults/prefs/all-thunderbird.js
(In reply to comment #8) > That's interesting... and it leaves me wondering why the obscure value is set > in both config files by default and why Firefox reads its value from > ./greprefs/all.js while Thunderbird reads its value from > ./defaults/prefs/all-thunderbird.js all.js is the main default configuration file for all Mozilla based apps. all-thunderbird.js is an additional file with specific for Thunderbird settings, e.g. mail & newsgroup stuff that doesn't apply to FF or other apps. I tried having a look through history, but could easily find why it was added to Thunderbird's file.
> I tried having a look through history, but could easily find why it was added > to Thunderbird's file. bug 228791 says the reason was "Mozilla uses 13. Tbird wants to have unobscured .cfg files, by default."
So if anything can be done about this as currently summarized, it can only be done in Thunderbird, moving back from Core to Thunderbird.
Component: General → Preferences
Product: Core → Thunderbird
QA Contact: general → preferences
If you want to obfuscate your file on thunderbird, you can add the preference: pref('general.config.obscure_value', 13); Then Thunderbird will properly decode the file. Thunderbird chose to have unobscured config files. Firefox still obscures (although I opened a bug to get that changed). So is there still an issue here or can the bug be closed?
Mike, the problem is not yet solved. The issue here is that this value is already added to the preferences file by default yet apparantly contradicted some place else. This means that a rotated file cannot be read. The logical solution to this would be to remove this setting from the preferences so it is not in there by default.
Here's what I did to read a byteshifted file on Thunderbird. 1. In the directory defaults/pref where the Thunderbird executable is located, create a file called autoconfig.js (it can have any name). 2. In that file, put: pref('general.config.obscure_value', 13); pref('general.config.filename', 'thunderbird.cfg'); The first line is what resets the obscure value to 13 (and overrides anything that has been set elsewhere). The second line is what sets the config name. 3. Create a file called thundebird-unshifted.cfg in the same directory where the Thunderbird executable is located and place this in it: // First line displayError("Test", "Test"); 4. Use the moz-byteshift.pl tool to shift the file by 13 bytes: perl moz-byteshift.pl -s 13 < thunderbird-unshifted.cfg > thunderbird.cfg (The perl script can be downloaded here - https://developer.mozilla.org/en/Automatic_Mozilla_Configurator/Locked_config_settings) 5. Then I started Thunderbird and the error box was displayed. This was on Windows. The way to overload the default Thunderbird obscure value is to specify a new value in a .js file under defaults/pref. That's the only place it can be overridden.
I still don't understand the issue here. Thunderbird defaults to unobscured AutoConfig files. If you want to obscure them, you have to set a preference to obscure them.
per comment 15 and irc discussion, "TB doesn't ROT13 the files", invalid
Status: UNCONFIRMED → RESOLVED
Closed: 11 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.