Error while decrypting the ciphertext provided to safeStorage.decryptString

[Dryadxon]

VSCodium can't retrieve the secrets it stores with the new SecretStorage API, in my case the authentication code for Codeium.
I followed these steps, and from the logs, both before and after authentication, it appears that VSCode correctly recognizes GNOME, and libsecret, but still fails with error Error while decrypting the ciphertext provided to safeStorage.decryptString.

I also tried a clean setup, with no customization or override, in a new Gnome User, with only the extension for Codeium, but unfortunately nothing changed.

The error is also present with VSCode.

Operating System : Fedora 38.
DE: Gnome.

PS: Other applications, e.g. Tuba, don't have this problem, unfortunately I can't tell if it's only present with VSCode derivatie applications, or if it affects other Electron apps.

Possible related issues:

• Keyring/Safe storage issue: Encrpytion is not available. VSCodium/vscodium#1563
• [Bug]: safeStorage.decryptString - Error while decrypting the ciphertext electron/electron#32598
• Flatpaked VSCode 1.80.1 cannot sync com.visualstudio.code#417
• I have to login with Github on every launch for sync to work. com.visualstudio.code#426
• VS Code detects KDE instead of GNOME for password store com.visualstudio.code#415

[noonsleeper]

Hi @Dryadxon, is still a problem with the news version?

[Dryadxon]

Unfortunately no, the bug is still there.
Here the logs before and after the authentication with the latest release on Flathub (1.83.1.23285).

[noonsleeper]

@Dryadxon are you tried this? https://code.visualstudio.com/docs/editor/settings-sync#_recommended-configure-the-keyring-to-use-with-vs-code

[Dryadxon]

@Dryadxon are you tried this? https://code.visualstudio.com/docs/editor/settings-sync#_recommended-configure-the-keyring-to-use-with-vs-code

Yeah, I tried all the steps listed in the link I gave you, including those, unfortunately it didn't change the situation, even using the basic option didn't help.

[noonsleeper]

This works with vscodium installed directly on host from the rpm package?

[Dryadxon]

It works when installed on the host, just tried it a few minutes ago. Both VSCodium and VSCode.

[Dryadxon]

I was able to reproduce the issue with the following minimal Electron app:

const { app, safeStorage } = require('electron')
const fs = require('fs')

const decrypt = (path) => {
    console.log('Decryption: START')

    try {
        const secret = fs.readFileSync(path)
        const decrypted = safeStorage.decryptString(secret)

        console.log(`The secret is: ${decrypted}`)
        return true
    } catch (e) {
        console.error(e)
    }

    console.log('Decryption: STOP')
    return false
}

const encrypt = (path) => {
    console.log('Encryption: START')

    const secret = safeStorage.encryptString('my secret')
    fs.writeFileSync(path, secret)

    console.log('Encryption: STOP')
}

app.whenReady().then(() => {
    const path = './tmp.txt'

    if (safeStorage.isEncryptionAvailable()) {
        console.log(safeStorage.getSelectedStorageBackend())

        if (!decrypt(path)) {
            encrypt(path)
        }
    }
})

So I can say with a bit of confidence that it's a problem of the Electron framework with flatpak. Unfortunately I can't figure out what the cause is, looking at the os_crypt_linux.cc implementation everything seems ok, and not everyone seems to have the same problem even though they also use Fedora Gnome.

[Dryadxon]

The only thing I can say for sure are these:

• On my system, a Lenovo Ideapad 15 ARE05 with Fedora 39 Gnome, all electron applications distributed as flatpaks are affected by the problem. For some reason, Chromium resets its encryption key every time it runs.
• It doesn't affect host-installed electron apps (RPM packages), these keep their key with each execution.

[Dryadxon]

I think that OSCryptImpl::GetPasswordV11() may be the most likely cause, but I can't debug Chomium directly while running my Electron app despite countless attempts. I hope someone more experienced can help out.

[aamplugin]

I've just experience the same issue and for the additional context - I've tried to decrypt encrypted string in the main process during app.on('ready', createWindow).

Most likely Electron haven't loaded all the necessary system resource, so it can't correctly determine the password. See the comment above from @Dryadxon.

Consider moving the code that decrypts secret value later in the Electron's life-cycle and that should work. At least it worked for me.

[Dryadxon]

Most likely Electron haven't loaded all the necessary system resource, so it can't correctly determine the password.

I think so too, every log made after a service authentication (e.g.: Copilot, Codeium) reports OSCrypt generated a new password, which means that KeyStorageLibsecret::GetKeyImpl can't retrieve the password to decrypt the secrets. What's interesting is that this problem was also noticed for Chromium two years ago, but unfortunately the only tested workaround seems to be to downgrade libsecret.

Consider moving the code that decrypts secret value later in the Electron's life-cycle and that should work. At least it worked for me.

Could you share the suggested changes?

[aamplugin]

@Dryadxon absolutely. My project is quite large, so I can't share all the code, but essentially here is what did not work for.

In the main.js file, basically file that main thread I've tried to check if there is a very specific encrypted property stored in MacOS key chain in the createWindow function:

Normally, you would expect that the ready ElectronJS event is a reasonable indication that all resources have been loaded and the entire framework can be used. However, that was not the case.

So I had to pivot.

At the moment I see two quick solutions:

• You can delay the decryption by setting timeout setTimeout in the main.js file for a second or two. Not ideal, but this gives enough time for the ElectronJS framework to finish the load.
• From the Renderer thread ping Main thread to trigger the decryption.

In my case, I used the second option.

[Dryadxon]

• You can delay the decryption by setting timeout setTimeout in the main.js file for a second or two. Not ideal, but this gives enough time for the ElectronJS framework to finish the load.

• From the Renderer thread ping Main thread to trigger the decryption.

For some reason neither of those worked on my machine, I even tried a timeout of 30sec, but still nothing, it fails to decrypt secrets and keeps generating a new password every time it is executed.

[Dryadxon]

I tried again to set --password-store="basic" and it works now, I know it's not safe, but it's still an improvement.
After the authentication token is stored this way, I can use VSCodium normally, even changing back to --password-store="gnome" but from the logs it seems to just fallback to the secret stored as obfuscated text, the underlying problem it's not solved, but at least exists a workaround.

[ghost]

Can people who were investigating this issue check if #319 fixed the issue ?

[Dryadxon]

Can people who were investigating this issue check if #319 fixed the issue ?

Tested today, unfortunately it didn't solve it. VSCodium still fails to decrypt secrets with GNOME_LIBSECRET as the OSCrypt backend.