525657 - Migration Wizard Does Not Correctly Migrate Composer Publisher Passwords

Status: NEW

(SeaMonkey :: Passwords & Permissions, defect)

Description

[therube]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.5pre) Gecko/20091023 SeaMonkey/2.0.1pre
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.5pre) Gecko/20091023 SeaMonkey/2.0.1pre

 
While Migration Wizard does migrate passwords, it does not correctly migrate Composer Publish Settings site login information correctly.  The passwords are not formatted correctly & so are not usable with Composer Publish Settings.

Further if you attempt to create & save a new Publishing Site (& Save Password), data loss occurs, where you loose all but the first (previously) saved Publish Site (prefs.js) records, & the "saved" password data does not get updated into Password Manager.
 

Reproducible: Always

Steps to Reproduce:
 
SeaMonkey1:
1. create new Profile
2. open Composer, Edit | Publish Site Settings...
3. create (3) test Server Sites, including saving the username/password
4. close SM1

SeaMonkey2:
1. run seamonkey -P 20.dumy2 -migration
2. open Password Manager.  verify that the FTP (Composer) sites have migrated.
3. open Composer, Edit | Publish Site Settings...
4. verify that the "Sites" appear, including the "User name:", but no password data appears
 
Actual Results:  
 
Password: field data is blank
 

Expected Results:  
 
Password: field data should be filled in with the migrated password, obtained from Password Manager
 

 
Appears that SM1 is storing in PWM the "site" such as ftp://user_name@publishing_address, but the migration of the password data into SM2 PWM is truncating that, storing only ftp://publishing_address. It is dropping the user_name part. Because of that, there is no longer a correlation between PWM & Site Manager, hence no password displays or is used if you attempt to publish.

SM1 will not save a password unless both the User Name: and Password: fields are filled out.

Further it appears that if you were to add a New Publish Site from within SM2, Composer, that all but the first (previously saved <you did make 3 sites in the outset>) sites then disappear from Site Manager (& prefs.js).

At that point, it looks like both prefs.js & signons.sqlite are corrupted. prefs.js has lost all but one Publishing Site Settings data set, & signons.sqlite will no longer save Publishing Site passwords (though the existing ones do remain & new "regular" passwords are being saved).

Just to note:

On a -migrate, *.s is being copied over from SM1 into the SM2 Profile, along with the Preference signon.SignonFileName pointing to *.s is being set in prefs.js.

Publish Settings (editor.publish.site*) prefs.js data entries between SM1 & SM2 look to be equivalent.

/Natively/ created Publish Settings Site password as stored in Password Manager, are stored differently between SM1 & SM2.

SM1, the "Site" field in Password Manager shows as:
ftp://user_name@publishing_address
<this is truncated on migration>

SM2, the "Site" field in Password Manager shows as:
ftp://user_name@publishing_address (ftp://user_name@publishing_address)
<the "Site" is displays as shown including the duplication in the parentheses, for whatever reason>

There is good potential for data loss, both in prefs.js & signons.sqlite.

Comment 1

[therube]

Attachment: SM1 Publisher/PWM

SM1 Publisher & Password Manager shots.  Publisher password is there (though obscured). PWM "Site" is of form ftp://user_name@publishing_addr.

Comment 2

[therube]

Attachment: SM2 Publisher/PWM

Migrated SM2 Publisher & Password Manager shots.  Publisher password is missing. PWM "Site" is of form ftp://publishing_addr.  The user_name@ has been truncated.

Comment 3

[therube]

Attachment: SM2 natively created Publisher/PWM

SM2 natively created Publisher & Password Manager shots.  Publisher password is there (though obscured). PWM "Site" is of form ftp://user_name@publishing_addr (ftp://user_name@publishing_addr).

Comment 4

[Philip Chee]

therubes reports are usually pretty reliable. And there are known problems with our migration code wrt Composer passwords.