Describe the bug
The pre-built base environment shipped with the Sema4.ai SDK extension (v2.19.0) contains OpenSSL 3.5.0 (openssl-3.5.0-ha4e3fda_1, 8 Apr 2025), which is affected by lots of vulnerabilities already. The base env is = distributed as a hash-pinned, pre-built archive (a2eefcb6eb765393-windows_amd64.zip), so users cannot upgrade OpenSSL through any supported path — rcc restores the env from the prebuilt zip rather than re-solving from conda-forge. The fix must come from a rebuilt base in a new extension release. Requesting the base be rebuilt against OpenSSL >= 3.6.3.
To Reproduce
Steps to reproduce the behavior:
- Install the Sema4.ai SDK extension (v2.19.0) and let it build its base environment (space
vscode-base-*).
- Inspect the OpenSSL build in the materialized holotree:
<holotree>/python.exe -c "import ssl; print(ssl.OPENSSL_VERSION)"
- See that it reports
OpenSSL 3.5.0 8 Apr 2025, and that conda-meta/openssl-*.json is openssl-3.5.0-ha4e3fda_1.
- Confirm the source spec
bin/create_env/conda_vscode_windows_amd64.yaml pins python=3.11.10, which pulls OpenSSL 3.5.0 transitively.
Expected behavior
The base environment ships with OpenSSL >= 3.6.3 (no known vulnerability).
Fix by adding an explicit constraint to the base specs (e.g. - openssl>=3.6.3)
or bumping the Python pin to a build whose transitive OpenSSL is >= 3.6.3, then
regenerating the pre-built base archives and updating getBaseAsZipBasename.
The sibling specs are likely also affected and should be rebuilt too:
conda_vscode_linux_amd64.yaml, conda_vscode_darwin_amd64.yaml,
conda_vscode_darwin_arm64.yaml.
Screenshots
N/A — evidence is the command output above (ssl.OPENSSL_VERSION →
OpenSSL 3.5.0 8 Apr 2025) and the conda-meta/openssl-3.5.0-ha4e3fda_1.json
record in the base holotree.
Versions:
- OS: Windows 11 (x64)
- Robot Framework Version: N/A — Sema4.ai SDK base env, Python 3.11.10 / OpenSSL 3.5.0
- Robot Framework Language Server Version: N/A — Sema4.ai SDK extension base env (blueprint
a2eefcb6eb765393)
- Client Version: VS Code with Sema4.ai SDK extension
sema4ai.sema4ai 2.19.0 (win32-x64)
Disclaimer:
- Used Claude Code to debug the issue and draft the Issue
Describe the bug
The pre-built base environment shipped with the Sema4.ai SDK extension (v2.19.0) contains OpenSSL 3.5.0 (
openssl-3.5.0-ha4e3fda_1, 8 Apr 2025), which is affected by lots of vulnerabilities already. The base env is = distributed as a hash-pinned, pre-built archive (a2eefcb6eb765393-windows_amd64.zip), so users cannot upgrade OpenSSL through any supported path —rccrestores the env from the prebuilt zip rather than re-solving from conda-forge. The fix must come from a rebuilt base in a new extension release. Requesting the base be rebuilt against OpenSSL >= 3.6.3.To Reproduce
Steps to reproduce the behavior:
vscode-base-*).<holotree>/python.exe -c "import ssl; print(ssl.OPENSSL_VERSION)"OpenSSL 3.5.0 8 Apr 2025, and thatconda-meta/openssl-*.jsonisopenssl-3.5.0-ha4e3fda_1.bin/create_env/conda_vscode_windows_amd64.yamlpinspython=3.11.10, which pulls OpenSSL 3.5.0 transitively.Expected behavior
The base environment ships with OpenSSL >= 3.6.3 (no known vulnerability).
Fix by adding an explicit constraint to the base specs (e.g.
- openssl>=3.6.3)or bumping the Python pin to a build whose transitive OpenSSL is >= 3.6.3, then
regenerating the pre-built base archives and updating
getBaseAsZipBasename.The sibling specs are likely also affected and should be rebuilt too:
conda_vscode_linux_amd64.yaml,conda_vscode_darwin_amd64.yaml,conda_vscode_darwin_arm64.yaml.Screenshots
N/A — evidence is the command output above (
ssl.OPENSSL_VERSION→OpenSSL 3.5.0 8 Apr 2025) and theconda-meta/openssl-3.5.0-ha4e3fda_1.jsonrecord in the base holotree.
Versions:
a2eefcb6eb765393)sema4ai.sema4ai2.19.0 (win32-x64)Disclaimer: