GitHub Extension Requests Authentication Every Time on Gnome

[czhang03]

Step to reproduce

• Remove current installation of vscodium, storage, and all its key in the keyring.
• Install vscodium, clone a private repo via https URL from GitHub.
• The GitHub extension should pop up, complete the authorization process.
• Close vscodium, wait a couple mins or log out to ensure it is fully closed
• Open vscodium and attempt to pull the private repo, notice that the GitHub extension will require authentication again.

Comment

I think it is probably just some key is not written to the keyring. It seems like signal flatpak also have similar issue flathub/org.signal.Signal#723 .

I wonder if this is related to electron decided to only support a not-yet-alpha version of xdg-desktop-protal electron/electron#43819 , since "gnome-keyring implements the Secret portal backend" (https://wiki.archlinux.org/title/XDG_Desktop_Portal).

Please let me know if this is just me experiencing this issue...

[zentasumu]

Was just about to create an issue for this as I am on the same boat, under fedora sericea 41.
Yeah, it seems to fail storing credentials, but I can confirm the native package works.

I have found a workaround for the time being, which is to mimic what the native package does with the keyring:

$ secret-tool store --label='Chrome Safe Storage' 'application' 'VSCodium' 'app_id' 'com.vscodium.codium' <<< "storepassword"

Both the app_id and application attributes need to be set to those respective values for things to work.

There is an error though related to a bug since 2016, but it seems we can disregard it for now:

[20:1106/025334.237722:VERBOSE1:libsecret_util_linux.cc(169)] Dummy store to unlock the default keyring failed: invalid password returned from portal

I already tried making a dummy store as well but the error above persists so don't bother with that one.

Hope this helps.

[noonsleeper]

Hi @czhang03 and @zentasumu, maybe you can look at #239 also https://code.visualstudio.com/docs/editor/settings-sync#_recommended-configure-the-keyring-to-use-with-vs-code

[zentasumu]

Hi @czhang03 and @zentasumu, maybe you can look at #239 also https://code.visualstudio.com/docs/editor/settings-sync#_recommended-configure-the-keyring-to-use-with-vs-code

Ah yes I have already followed those instructions to no avail as well.

And apologies, with the workaround I've mentioned here is the log:

[20:1107/233411.981195:INFO:CONSOLE(35)] "%cTRACE color: #888 [mainThreadSecretState] Getting password for gitlab.gitlab-workflow extension:  gitlab-tokens", source: vscode-file://vscode-app/app/share/codium/resources/app/out/vs/workbench/workbench.desktop.main.js (35)
[20:1107/233411.981423:VERBOSE1:key_storage_linux.cc(118)] Selected backend for OSCrypt: GNOME_LIBSECRET
�[90m[main 2024-11-07T15:34:11.981Z]�[0m [EncryptionMainService] Checking if encryption is available...
[20:1107/233412.006273:VERBOSE1:key_storage_linux.cc(165)] OSCrypt using Libsecret as backend.
[20:1107/233412.011857:VERBOSE1:key_storage_libsecret.cc(53)] Libsecret key created: 2024-11-05 18:51:53.000000 UTC
[20:1107/233412.011875:VERBOSE1:key_storage_libsecret.cc(54)] Libsecret key last modified: 2024-11-06 08:39:52.000000 UTC
[20:1107/233412.011878:WARNING:key_storage_libsecret.cc(55)] the encryption key has been modified since it was created.
�[90m[main 2024-11-07T15:34:12.012Z]�[0m [EncryptionMainService] Encryption is available:  true
[20:1107/233412.012638:INFO:CONSOLE(35)] "%cTRACE color: #888 [SecretStorageService] Encryption is available, using persisted storage", source: vscode-file://vscode-app/app/share/codium/resources/app/out/vs/workbench/workbench.desktop.main.js (35)
[20:1107/233412.012803:INFO:CONSOLE(35)] "%cTRACE color: #888 [secrets] getting secret for key: secret://{"extensionId":"gitlab.gitlab-workflow","key":"gitlab-tokens"}", source: vscode-file://vscode-app/app/share/codium/resources/app/out/vs/workbench/workbench.desktop.main.js (35)
[20:1107/233412.012855:INFO:CONSOLE(35)] "%cTRACE color: #888 [secrets] decrypting gotten secret for key: secret://{"extensionId":"gitlab.gitlab-workflow","key":"gitlab-tokens"}", source: vscode-file://vscode-app/app/share/codium/resources/app/out/vs/workbench/workbench.desktop.main.js (35)
�[90m[main 2024-11-07T15:34:12.013Z]�[0m [EncryptionMainService] Decrypting value...
�[90m[main 2024-11-07T15:34:12.013Z]�[0m [EncryptionMainService] Decrypted value.
[20:1107/233412.013496:INFO:CONSOLE(35)] "%cTRACE color: #888 [secrets] decrypted secret for key: secret://{"extensionId":"gitlab.gitlab-workflow","key":"gitlab-tokens"}", source: vscode-file://vscode-app/app/share/codium/resources/app/out/vs/workbench/workbench.desktop.main.js (35)
[20:1107/233412.013568:INFO:CONSOLE(35)] "%cTRACE color: #888 [mainThreadSecretState] Password found for:  gitlab.gitlab-workflow gitlab-tokens", source: vscode-file://vscode-app/app/share/codium/resources/app/out/vs/workbench/workbench.desktop.main.js (35)

[czhang03]

I am fairly sure this is pretty recent, did codium recently changed the default secret storage from plain text to gnome keyring?

[czhang03]

Signal Seems to think that their secrete-storage problem is related to this issue: https://gitlab.gnome.org/GNOME/libsecret/-/issues/49 , maybe we can try similar workarounds as suggested in the issue.

Source: flathub/org.signal.Signal#756

[daiyam]

did codium recently changed the default secret storage from plain text to gnome keyring?

The flatpak is now based on the runtime 24.08 (#364). It's the only notable change but I don't know if there is an impact.

On the core app, no changes on our end (VSCodium) have been made to change the default secret storage. But maybe VSCode did.

[noonsleeper]

@daiyam This problem was present for so long on this repo, that workaround looks fine, but I will look if libsecret can be compiled from a git repo instead of that artifact then flatpak-external-data-checker can take care or notify us when libsecret is updated. I'll add this on codium-insiders repo first to test.

@czhang03 thanks.

[noonsleeper]

@zentasumu @czhang03 you can test this flathub/com.vscodium.codium-insiders#46 (comment) to confirm if this already fix the problem?

[zentasumu]

@zentasumu @czhang03 you can test this flathub/com.vscodium.codium-insiders#46 (comment) to confirm if this already fix the problem?

It works. The necessary login entries are being created in the keyring now, and the credentials (for Gitlab Workflow extension in my case) doesn't need to be re-added upon re-launch.

[czhang03]

I think this issue probably can be safely closed, and if I find any bug during testing, I will try to reopen it.

[noonsleeper]

I think this issue probably can be safely closed, and if I find any bug during testing, I will try to reopen it.

I preferred this issue open until we merge the changes in codium, as a remainder

[noonsleeper]

ok with the latest update the fix was introduced in master in 8 hours you can update to the latest version. I will close this.