Saved Logins not available in 10.5

moved from tor-browser-build#40326 (moved)

While the password manager is not supported in Tor Browser, we don't intentionally break it.

One work around for recovering the saved passwords (as I understand it) is:

Download Tor Browser 10.0.18
Install/Start Tor Browser
Quit Tor Browser
Copy logins.json (and maybe cert.db and keys.db) from Tor Browser 10.5 profile to new Tor Browser 10.0.18 profile
Start Tor Browser 10.0.18

It seems this is an issue with the Master Password logic. In 10.5, creating a new Login without setting a master password fails, and setting a master password fails. In 10.0.18 these actions are successful. Maybe this has something do do with the idb migration (?).

Nope. Flipping extensions.webextensions.ExtensionStorageIDB.enabled doesn't fix it.

When creating a new Login, in a red error bar I get:

An error occurred while trying to save this password.

and in a yellow error bar:

Please enter your master password to view saved logins & passwords

Related log messages:

JavaScript error: resource://gre/modules/XULStore.jsm, line 66: Error: Can't find profile directory.
console.debug: LoginManager: "Getting a list of all logins asynchronously"
console.log: Login storage: "_searchLogins: returning" 0 "logins for" ({}) "with options" ({schemeUpgrades:false, acceptDifferentSubdomains:false})

console.debug: LoginManager: "Adding login"
console.log: Login storage: "ensureDataReady"
console.log: Login storage: "checkLoginValues"
console.log: Login crypto: "Failed to encrypt string. (NS_ERROR_FAILURE)"
console.log: Login crypto: "Prompted for a master password, notifying for passwordmgr-crypto-loginCanceled"
JavaScript error: resource://gre/modules/crypto-SDR.js, line 90: NS_ERROR_ABORT: User canceled master password entry

about:logins works in 10.5a17.

It seems that this is failing in one of three places, either in SecretDecoderRing::Encrypt:

  if (PK11_Authenticate(slot.get(), true, ctx) != SECSuccess) {
    return NS_ERROR_FAILURE;
  }

  /* Make sure token is initialized. */
  nsCOMPtr<nsIInterfaceRequestor> ctx = new PipUIContext();
  nsresult rv = setPassword(slot.get(), ctx);                                                                                                                                                              
  if (NS_FAILED(rv)) {
    return rv; 
  }

 if (PK11SDR_Encrypt(&keyid, &request, &reply, ctx) != SECSuccess) {
    return NS_ERROR_FAILURE;
  }

 if (PK11SDR_Encrypt(&keyid, &request, &reply, ctx) != SECSuccess) {
    return NS_ERROR_FAILURE;
  }

This is the winner. In PK11SDR_Encrypt we try creating the default key, and that fails.

       if (!key)
            key = PK11_GenDES3TokenKey(slot, pKeyID, cx);
[...]
    if (!key) {
        rv = SECFailure;
        goto loser;
    }

PK11_GenDES3TokenKey calls PK11_TokenKeyGen, calls pk11_TokenKeyGenWithFlagsAndKeyType, calls PK11_KeyGenWithTemplate, calls PK11_GETTAB->C_GenerateKey (NSC_GenerateKey), calls sftk_handleObject,and that returns on:

    if (((session->info.flags & CKF_RW_SESSION) == 0) &&
        (sftk_isTrue(object, CKA_TOKEN))) {                                                                                                                                                                
        return CKR_SESSION_READ_ONLY;
    }

/* The flags are defined in the following table:
 *      Bit Flag                Mask        Meaning
 */
#define CKF_RW_SESSION 0x00000002UL     /* session is r/w */
#define CKF_SERIAL_SESSION 0x00000004UL /* no parallel */

And session->info.flags is 0x4.

PK11_KeyGenWithTemplate calls PK11_GetRWSession, and that calls NSC_OpenSession; but maybe something else is going wrong in there.

@richard could this be related to #40490 (closed)? There aren't too many changes that landed between 10.5a17 and 10.5, and most shouldn't have any impact on PSM/NSS.

changed the description

assigned to @richard

A status update on this bug:

So this is a weird one to debug. I suspect this problem has to do with something apart from a code change, as doing a git bisect, and deploying over the broken build, never gets us back to a working state (eg even when going before this broke in our alphas). After bisection failed to find a commit to blame, I started debugging.

I started diving into the failing call when we attempt to set a master password. The call fails as if there were no cert db, and it turns out that's because there is no cert db (despite the pref being set correctly). Much debugging later, i've found it's because our call to InitializeNSSWithFallbacks() (which happens during firefox launch) ends up falling back on to NSS_NoDB_Init() after attempts to read an existing db fails. As to why it fails, I have no idea I'm still digging through.

mentioned in merge request !177 (closed)

So the problem here is that tor-launcher-protocol-service (which calls into and will lazily init the nsNSSComponent) was being created too soon due to being pulled in via the TorProtocolService init in BrowserGlue.jsm

Here's the offending JS Stack Trace in case we run into this issue again:

0 get _RNGService() ["jar:file:///home/pospeselr/Code/tor-browser/.binaries/dev/Browser/browser/omni.ja!/chrome/torlauncher/components/tl-protocol.js":1376:28]
    this = [object Object]
1 _crypto_rand_int(aMax = "94") ["jar:file:///home/pospeselr/Code/tor-browser/.binaries/dev/Browser/browser/omni.ja!/chrome/torlauncher/components/tl-protocol.js":1267:18]
    this = [object Object]
2 _generateRandomPassword() ["jar:file:///home/pospeselr/Code/tor-browser/.binaries/dev/Browser/browser/omni.ja!/chrome/torlauncher/components/tl-protocol.js":1186:21]
    this = [object Object]
3 TorProtocolService() ["jar:file:///home/pospeselr/Code/tor-browser/.binaries/dev/Browser/browser/omni.ja!/chrome/torlauncher/components/tl-protocol.js":88:35]
    this = [object Object]
4 <TOP LEVEL> ["jar:file:///home/pospeselr/Code/tor-browser/.binaries/dev/Browser/browser/omni.ja!/chrome/torlauncher/components/tl-protocol.js":1563:26]
5 <TOP LEVEL> ["resource:///modules/TorProtocolService.jsm":12:62]
6 <TOP LEVEL> ["resource:///modules/BrowserGlue.jsm":20:43]

tl-protocol.js cannot be init'd until after profile-after-change.

Fixed in !177 (closed)

mentioned in issue tpo/web/manual#99 (closed)

mentioned in merge request !179 (merged)

New more durable link for Tor Browser 10.0.18 (since the link above is now 404):
https://archive.torproject.org/tor-package-archive/torbrowser/10.0.18/

Not sure if this is helpful, but this reminds me of issue #33540 (closed), introduced in v9.0.x, where TB fails to create permissions.sqlite even if the prefs to do so are enabled, for unknown reasons.

This was fixed in !179 (merged)

closed

mentioned in issue #40555 (closed)

marked this issue as related to #40555 (closed)

Backported as e81a03a2

Saved Logins not available in 10.5

Designs

Child items ...

Activity