[debug] detected desktop environment: CINNAMON
[debug] Chosen keyring: GNOMEKEYRING

Are these detected correctly?

cc @mbway

(also note that --cookies-from-browser doesn't work with panopto iirc due to the use of session cookies)

@pukkandan Yes about Cinnamon, not sure about GNOMEKEYRING how do i check?

@coletdjnz How do i download form panopto than?

@pukkandan Yes about Cinnamon, not sure about GNOMEKEYRING how do i check?

@coletdjnz How do i download form panopto than?

You will need to manually export the cookies from your browser. Note that in my experience this has to be done every so often for panopto.

https://github.com/yt-dlp/yt-dlp/wiki/FAQ#how-do-i-pass-cookies-to-yt-dlp

As for why some cookies aren't decrypting properly, this looks like another case where the password is not obtained correctly, but the reason why isn't obvious. Like with previous cases, some cookies are reported successful decrypted. I think this just means decryption finished without error but the result could still be wrong.

A basic (but not foolproof) check for whether chromium is using the gnome keyring would be to run seahorse and see if you see a Chromium Safe Storage entry.

Since you're concerned with Panopto you may not be interested in troubleshooting this issue further, but if you are:

If you could install another chromium based browser that you haven't used before (eg brave), log into a service like youtube and attempt --cookies-from-browser brave I wonder if that would work. If it doesn't I may install mint for myself and see if I can reproduce the issue.

If you are on Linux, things like tmux may somehow affect how the decryption key is grabbed (in my case via KWallet 5). Most often I have to use yt-dlp without tmux.

that is bizarre if that's the case. I can't reproduce the issue. I tried the following situations:

• Arch
• Plasma 5.27 + KWallet
• tmux 3.3
• Konsole and Terminator
• Brave, Chromium and Firefox

I had no issues. If you can find a situation that repeatably breaks I can take a look

I was having the same issue with chromium browser (Gnome desktop)

Using seahorse I saw that I had multiple Chromium Safe Storage entries.
In the details of these entries there is a key application, which was set to application: chromium for one of the entries, but other ones were application: discord and application: slack.
Once I deleted the other entries, leaving only application: chromium one, the cookie extraction started working.

@Despruk Thank you. This helped me to solve the same problem. In my case it was Discord and VSCode that created another Chromium Safe Storage.
But it would be preferable for yt-dlp to check application field to find the right entry.

After a system and likely Chrome update, getting this error again. Chrome Beta 130.0.6723.6

[debug] Extracting cookies from: "/home/tatsh/.config/google-chrome/Default/Cookies"
[Cookies] Loading cookie      0/  2967[debug] detected desktop environment: KDE6
[debug] Chosen keyring: KWALLET6
[debug] using kwallet-query to obtain password from KWALLET6
[debug] NetworkWallet = "kdewallet"
[debug] password found
[Cookies] Loading cookie      1/  2967WARNING: failed to decrypt cookie (AES-CBC) because UTF-8 decoding failed. Possibly the key is wrong?

Any news ?
Use MacOS sequoia 15.0 darwin_x64 chromium 130.0.6690.0

[Cookies] Loading cookie      0/   582WARNING: failed to decrypt cookie (AES-CBC) because UTF-8 decoding failed. Possibly the key is wrong?

Most likely it's the same issue as this
thewh1teagle/rookie#50

Most likely it's the same issue as this thewh1teagle/rookie#50

That issue looks like it only applies to Windows.

sorry, with the rookie issue being posted so recently I assumed it had to be related without looking carefully.

Although the symptom is the same as the original post in this issue thread, this probably warrants a new issue being opened since the cause of these new decryption issues is clear (caused by chrome upgrade).

I have been able to reproduce the error with chrome 130.0.6723.19 on Arch/KDE6.

I read through the changelog for recent changes to cookie storage in chromium but didn't find anything obvious that could be causing the breakage.

https://chromium.googlesource.com/chromium/src/+log/refs/heads/main/components/os_crypt

I tried playing around with some data as well and have some notes:

• a hand-crafted example with values manually extracted from kwallet and the database still fail, so it isn't that the password is not being detected properly or something.
• google-chrome-beta is definitely still using kwallet (new folder created on first launch)
• looks like a fixed IV is still being used because many cookies had the same 32 bytes of ciphertext after the v11 prefix

This morning I was on an older Chrome beta (not updated machine, but not horribly out of date) and password decryption was still working. So it's definitely a very recent change.

What was the version of the working chrome? If it comes to bisecting commits it might narrow it down

The working version of beta was 128.0.6613.36 from about 2 months ago. Non-working likely 130.0.6723.6 and beyond (or perhaps 130.anything and beyond).

I also would say probably most or all of the 129 versions work but I cannot confirm. This is just based on that ever since about my update to 130.0.6723.6 the decryption stopped working.

https://github.com/gentoo/gentoo/commits/master/www-client/google-chrome-beta for versions I've been using.

I'm running into this after updating my system

Arch with Plasma 6.2.1 with kwallet disabled and --password-store=basic in chromium flags, chromum 130.0.6723.58-1

~/.config/kwalletrc contains

[Wallet]
Enabled=false

For yt-dlp using --cookies-from-browser chromium:/path/to/custom/profile and seeing

[debug] Extracting cookies from: "/path/to/custom/profile/Default/Cookies"
[Cookies] Loading cookie      0/  1154WARNING: failed to decrypt cookie (AES-CBC) because UTF-8 decoding failed. Possibly the key is wrong?
Extracted 705 cookies from chromium (434 could not be decrypted)
[debug] cookie version breakdown: {'v10': 1154, 'v11': 0, 'other': 0, 'unencrypted': 0}

where previously no issues.

and to help bisect this was the last version of chromium I was using where it was working: chromium-129.0.6668.58-1 from ~ Sept 17

I fixed it by hacking around the problem.

I tracked the "source" of this message:

WARNING: failed to decrypt cookie (AES-CBC) because UTF-8 decoding failed. Possibly the key is wrong?

The decryption of cookies is decoding the decrypted "plaintext" using UTF-8. And for some reason, I didn't yet track why exactly, there are 32 extra bytes of garbage at the beginning of the string. As others noted, this started very recently.

https://github.com/yt-dlp/yt-dlp/blob/2a24674/yt_dlp/cookies.py#L1013-L1021

The "return plaintext.decode()" is failing. After comparing values from different steps of the process against my actual cookies, I noticed there were simply extra bytes (garbage? idk...)

I changed it to cut off these extra bytes "return plaintext[32:].decode()" and it stopped failing (for all the cookies).

Hopefully this clue leads to someone solving the issue without hacking around it.

Maybe check the sources of Chromium?

the hack works here

chromium/chromium@129.0.6668.58...130.0.6723.58 has a bazillion changes. might need to bisect unless knowing where to look

just looking at the diff between those tags searching for keywords like AES CBC, may be some hints in various changes in chrome/browser/ash/platform_keys/platform_keys_service_* files. Like in platform_keys_service_nss.cc

-// Default signature length for signing with symmetric keys.
+// Default constants for symmetric keys.
+const int kDefaultSymKeySize = 32;
 const int kDefaultSymSignatureLength = 32;

that was just replacing a hard coded value, but maybe the 32 bytes is a key or signature idk

happening same with gallery-dl too!
I am on mac 15.0.1 (24A348) and latest chrome stable

I fixed it by hacking around the problem.

I tracked the "source" of this message:

WARNING: failed to decrypt cookie (AES-CBC) because UTF-8 decoding failed. Possibly the key is wrong?

The decryption of cookies is decoding the decrypted "plaintext" using UTF-8. And for some reason, I didn't yet track why exactly, there are 32 extra bytes of garbage at the beginning of the string. As others noted, this started very recently.

https://github.com/yt-dlp/yt-dlp/blob/2a24674/yt_dlp/cookies.py#L1013-L1021

The "return plaintext.decode()" is failing. After comparing values from different steps of the process against my actual cookies, I noticed there were simply extra bytes (garbage? idk...)

I changed it to cut off these extra bytes "return plaintext[32:].decode()" and it stopped failing (for all the cookies).

Hopefully this clue leads to someone solving the issue without hacking around it.

This works great! I think a PR should be made with this change as it will keep BC:

diff --git a/yt_dlp/cookies.py b/yt_dlp/cookies.py
index 4a69c576b..5a5dbe941 100644
--- a/yt_dlp/cookies.py
+++ b/yt_dlp/cookies.py
@@ -1016,7 +1016,10 @@ def _decrypt_aes_cbc_multi(ciphertext, keys, logger, initialization_vector=b' '
         try:
             return plaintext.decode()
         except UnicodeDecodeError:
-            pass
+            try:
+                return plaintext[32:].decode()
+            except UnicodeDecodeError:
+                pass
     logger.warning('failed to decrypt cookie (AES-CBC) because UTF-8 decoding failed. Possibly the key is wrong?', only_once=True)
     return None

This change is working well for me also, thanks 🎉

@kesor @Tatsh do one of you want to open a PR with that patch?

Backwards compatibility might be an issue since it will break for older versions and browsers using an older chromium base

@mbway If we try first with the full plaintext before slicing, that should be backwards compatible, yeah?

diff --git a/yt_dlp/cookies.py b/yt_dlp/cookies.py
index 4a69c576b..6ecc354cc 100644
--- a/yt_dlp/cookies.py
+++ b/yt_dlp/cookies.py
@@ -1013,10 +1013,11 @@ def pbkdf2_sha1(password, salt, iterations, key_length):
 def _decrypt_aes_cbc_multi(ciphertext, keys, logger, initialization_vector=b' ' * 16):
     for key in keys:
         plaintext = unpad_pkcs7(aes_cbc_decrypt_bytes(ciphertext, key, initialization_vector))
-        try:
-            return plaintext.decode()
-        except UnicodeDecodeError:
-            pass
+        for cookie in (plaintext, plaintext[32:]):
+            try:
+                return cookie.decode()
+            except UnicodeDecodeError:
+                pass
     logger.warning('failed to decrypt cookie (AES-CBC) because UTF-8 decoding failed. Possibly the key is wrong?', only_once=True)
     return None
 

The issue that was being discussed since 2024.10.01 was resolved by 4613096, and this issue has been closed.

As mbway said upthread though, the original post in this thread was about a different issue with merely the same symptom. Since mbway could not reproduce the issue, and since Despruk found a workaround for an external issue that may have been the same thing as the OP was experiencing, I am keeping this issue closed for now.

If the original author of this issue or anyone else experiences a problem similar to the original post using the latest version, then they can share a new complete verbose log and this issue can be reopened.