STM32CubeIDE for Visual Studio Code - Failed to download bundle repository index.

[thiago-pontes]

Hi, I am experiencing a bug in the latest version of the Extension for VS Code. As soon as I open the extension I receive this message:
"Unable to contact the STM32Cube registry, verify your Internet connection..."

If I run "cube bundle list-online" in the terminal I get this:

cube bundle list-online

Download attempt 2 out of 5 for https://developer.st.com/bundles/BundleRepositoryIndex.json ...

Download attempt 3 out of 5 for https://developer.st.com/bundles/BundleRepositoryIndex.json ...

Download attempt 4 out of 5 for https://developer.st.com/bundles/BundleRepositoryIndex.json ...

Download attempt 5 out of 5 for https://developer.st.com/bundles/BundleRepositoryIndex.json ...
Failed to list available online bundles: Failed to download bundle repository index: Failed to send request: error sending request for url (https://developer.st.com/bundles/BundleRepositoryIndex.json)

But if I install the STM32Cube Core - Version 1.1.0, everything works fine:

cube bundle list-online
 Name : Platform Version
 ---------------------------------------------------------------------
 adoptium-jre : x86_64-windows ["21.0.8+9.st.2", "17.0.16+8.st.1", "17.0.15+6.st.1", "17.0.14+7.st.6", "17.0.14+7.st.5"]
 cmake : x86_64-windows ["4.2.3+st.1", "4.0.1+st.3"]
 cube-cmsis-scanner : x86_64-windows ["2.4.2", "2.2.1", "1.1.3", "1.1.0", "1.0.1"]
 cube-code-doc : all ["0.0.7+st.2", "0.0.6+st.2", "0.0.5+st.1", "0.0.3+st.1", "0.0.2+st.1"]
 cube-code-manifest : x86_64-windows ["1.1.3+st.1", "1.0.9+st.2", "1.0.6+st.1", "1.0.3+st.1", "1.0.1+st.1", "1.0.0+st.1"]
 cube-wrapper : x86_64-windows ["0.10.2", "0.8.3", "0.7.3"]
 gnu-gdb-for-stm32 : x86_64-windows ["14.3.1+st.2", "13.3.1+st.10", "13.3.1+st.9"]
 gnu-tools-for-stm32 : x86_64-windows ["14.3.1+st.2", "13.3.1+st.9", "13.3.1+st.8"]
 gnu-tools-for-stm32-13_3_1-description : all ["1.0.1+st.1", "1.0.0+st.1"]
 gnu-tools-for-stm32-14_3_1-description : all ["1.0.1+st.2", "1.0.1+st.1"]
 ide-project-converter : all ["1.0.0"]
 jlink-gdbserver : x86_64-windows ["9.14.1+st.1", "8.80.0+st.1", "8.38.0+st.1", "8.12.3+st.3"]
 ninja : x86_64-windows ["1.13.2+st.1", "1.13.1+st.1", "1.12.1+st.9"]
 node : x86_64-windows ["22.22.0+st.1", "20.19.4+st.1", "20.18.3+st.3"]
 osgi-exporter : all ["0.0.4"]
 pack-manager : all ["0.5.3", "0.3.12", "0.3.8", "0.3.7"]
 pack-manager-snapshot : all ["2026.2.27", "2025.11.6", "2025.8.6", "2025.6.19", "2025.4.24"]
 programmer : x86_64-windows ["2.22.0+st.1", "2.21.0", "2.20.0", "2.19.0+st.1"]
 project_extractor : x86_64-windows ["1.2.0"]
 rtos-proxy : x86_64-windows ["0.18.1+st.3", "0.17.0+st.3"]
 st-arm-clang : x86_64-windows ["21.1.1+st.6", "19.1.6+st.10", "19.1.6+st.9", "19.1.6+st.8"]
 st-arm-clang-19_1_6-description : all ["0.0.5+st.1", "0.0.4+st.1"]
 st-arm-clang-21_1_1-description : all ["1.0.1+st.1"]
 st-arm-clang-hybrid : all ["21.1.1+st.2", "19.1.6+st.3", "19.1.6+st.2"]
 st-arm-clang-hybrid-19_1_6-description : all ["0.0.6+st.1", "0.0.5+st.1"]
 st-arm-clang-hybrid-21_1_1-description : all ["1.0.0+st.1"]
 st-arm-clangd : x86_64-windows ["21.1.0+st.2", "19.1.2+st.3"]
 stlink-gdbserver : x86_64-windows ["7.13.0+st.3", "7.12.0+st.2", "7.11.0+st.1", "7.10.0+st.3"]
 stlink-server : x86_64-windows ["2.1.1+st.8", "2.1.1+st.7"]
 stlink-upgrader : x86_64-windows ["3.17.10+st.1", "3.16.9+st.4", "3.16.8+st.3"]
 stlink-usb-driver : x86_64-windows ["2.1.2+st.5"]

Is there any breaking changes from 1.1.0 to 1.2.0?
Best regards

[Julien D]

Hello @thiago-pontes,

Is the issue systematic and still occurring now, or is it a random loss of connection?

[thiago-pontes]

Hi @Julien D,

With the version >1.2.0 the issue is systematic and consistent, I am not able to reach the st server at all. Using version 1.1.0 and below we have a random loss of connection (most of the time it can reach the server, but sometimes it can't).

[Julien D]

Are you behind a proxy?

If not please ensure that you don't have anything defined into your http.proxy vscode settings.

If so try to remove any http.proxyAuthorization and restart vscode.

[Nawres GHARBI]

Hi @thiago-pontes 

just to understand when you say you are not behind a proxy, are you on a persona network or company network ?

[Julien D]

Neither VPN connection?

Should work with proxy and/or VPN but trying to isolate your setup.

 

Out of curiosity, are you able to access to this url in a web-browser?

https://developer.st.com/bundles/BundleRepositoryIndex.json

 

[thiago-pontes]

I can access 

https://developer.st.com/bundles/BundleRepositoryIndex.json

in the browser.

But in the terminal (powershell):

PS C:\Users\thiag\Desktop> curl https://developer.st.com/bundles/BundleRepositoryIndex.json
curl: (35) schannel: next InitializeSecurityContext failed: SEC_E_ILLEGAL_MESSAGE (0x80090326) - This error usually occurs when a fatal SSL/TLS alert is received (e.g. handshake failed). More detail may be available in the Windows System event log.

 

[Julien D]

In powershell curl is an alias to Invoke-WebRequest, prefer using curl.exe instead, ideally with -vvv to view more logs.

[thiago-pontes]

Hi @Nawres GHARBI,
It is a personal network.

@Julien D, just to check the VPN side, I disabled ZeroTier (not a VPN for my machine, it is used to connect to remote machines, and should not interfere in my local working setup internet access). Then updated to STM32Cube Core V1.2.1, and restarted vscode. The issue still happens.

I reverted back to V1.1.0 then I can work normally with no errors.

[thiago-pontes]

I disabled it via the Windows registry:

This path: 

Computer\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.3\Client

 

[Julien D]

For the record, an internal ticket has been created as a follow-up to this issue.

[Thibault_B]

Hi @thiago-pontes 

 

We have tested different use case, using previous version of `cube-wrapper@0.8.3` and the newer one `cube-wrapper@0.10.2` which is the underlying bundle responsible for the issue you are encountering when issuing the following command

cube bundle list-online

.

We have tested on following platform: Windows 11 Pro 25H2, Windows 11 Pro 24H2,  Linux and WSL2.

Both behind proxy and without proxy. We didn't encounter any issue when issuing the same command as you.

 

Although we noted that either Windows 11 Pro 25H2, Windows 11 Pro 24H2 is by default using TLS v1.2 on previous cube-wrapper version:

• cube-wrapper 0.8.3 -> TLS 1.2

• cube-wrapper 0.10.2  -> TLS 1.3

 

Linux & WSL2:

• cube-wrapper 0.8.3 -> TLS 1.3

• cube-wrapper 0.10.2  -> TLS 1.3

 

Dependencies that we are using have been updated and this is why that Windows now uses TLS v1.3. 

We could reproduce the issue you had when enforcing TLS version to 1.0 or 1.1.

It seems the issue would probably come from you network settings / proxy blocking you or enforcing a TLS version older than v1.2.

[Pavel A.]

Additionally please check Windows event log for anything related to TLS failure.

There are few things that may prevent TLS 1.3 from working even if enabled in registry. One of them is FIPS mode enabled in the policy. 3rd party software also can cause this, if it spies (aka does "HTTPS inspection") on TLS 1.2, but cannot crack 1.3 yet. Since you get some invalid TLS response, this looks more likely.