All committers have signed the CLA.

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 7.32%. Comparing base (fe78ece) to head (c611fd7).
Report is 1 commits behind head on main.

@@          Coverage Diff          @@
##            main   #1221   +/-   ##
=====================================
  Coverage   7.32%   7.32%           
=====================================
  Files         20      20           
  Lines       1378    1378           
=====================================
  Hits         101     101           
  Misses      1277    1277           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

Hey @davzoku 👋

Thanks so much for your PR! Apologies for the long delay in looking at this. We had some other unrelated issues with our Python workflow that was causing build failures that should be resolved now. I went ahead and pulled in the new changes to this branch to see if they'll succeed with your new changes.

Checkmarx One – Scan Summary & Details – 33de00e2-51af-4d49-b055-f7e1d8ed9021

Great job, no security vulnerabilities found in this Pull Request

Thanks for pushing this in to the right direction @davzoku - I have not succeeded to build/install from your pr. I got ...LICENSE' trying to install outside the target directory '/var/home... and got it working here: https://github.com/goshansp/sdk-sm/tree/fix_pip_install_build_error

The main changes were removal of license-file.workspace = true from crates/bitwarden-py/Cargo.toml and symlinked LICENSE in bitwarden_sdk/. from root. Include path = "bitwarden_sdk/*" in pyproject.toml.

EDIT: I am able to install the resulting library but it will seqfault upon invocation. I have not managed to build and run it. I also tried building from main and the bahaviour is the same. I tried with Python 3.13 and 3.11 with same result. Can someone confirm that we have a working python branch?

@goshansp, thanks for looking at this.

I'm able to install the built wheel artifacts from this branch and invoke it successfully in a Python script. Here's what I used to quickly test it:

python3 -c '
import os;
from bitwarden_sdk import BitwardenClient, DeviceType, client_settings_from_dict;
client = BitwardenClient(
            client_settings_from_dict(
                {
                    "apiUrl": "http://localhost:3000/api",
                    "deviceType": DeviceType.SDK,
                    "identityUrl": "http://localhost:3000/identity",
                    "userAgent": "Python",
                }
            )
        );
client.auth().login_access_token(os.getenv("ACCESS_TOKEN"), None)
'

I was also able to build it locally and invoke it with the above script as well by doing the following:

# generate schemas
npm i
npm run schemas

# create a python virtual environment; I used uv so I could easily test with multiple Python interpreter versions
uv venv /tmp/.venv --python 3.13 # 3.9 worked for me as well
source /tmp/.venv/bin/activate

# install maturin
## on macOS:
uv pip install maturin

## on Linux:
uv pip install maturin[patchelf]

# build and install the Python package
maturin develop

Could you provide more information about your system (OS, CPU arch, any other relevant info about your Python environment) and how you're building and invoking the SDK so I can try to replicate it on my end?

Sincere thanks for your qualified comment @tangowithfoxtrot - I am rolling with Fedora 42 Silverblue in a Venv and on this branch I cannot python -c "import bitwarden_sdk" as to be seen below. I suspect there is something with the Fedora build chain / versions that I am missing.

Your Python snipped has an ident issue. I reverted to using this branches code to see if I can get it to work with your instructions. This is what I did:

LICENSE path issue

$ sudo rpm-ostree install --apply-live -y npm cargo
$ git clone https://github.com/davzoku/sdk-sm.git
$ cd sdk-sm/
$ switch fix_pip_install_build_error 
$ npm i
$ npm run schemas

$  python -m venv ~/.local/venv-bitwarden
$  source ~/.local/venv-bitwarden/bin/activate
$ pip install maturin[patchelf]

$ cd languages/python/
$ maturin develop
  Downloaded 62 crates (26.1MiB) in 0.82s (largest was `winapi-x86_64-pc-windows-gnu` at 2.8MiB)
💥 maturin failed
  Caused by: license file `/var/home/molecule/sdk-sm/LICENSE` exists outside of the project root `/var/home/molecule/sdk-sm/languages/python`
  Caused by: prefix not found

On My branch after fixing LICENCE

$ python -c "import bitwarden_sdk"
Segmentation fault (core dumped)

Build System Info

$ uname -a
Linux fcos-42.hp.molecule.lab 6.14.9-300.fc42.x86_64 #1 SMP PREEMPT_DYNAMIC Thu May 29 14:27:53 UTC 2025 x86_64 GNU/Linux
$ cargo --version
cargo 1.88.0 (873a06493 2025-05-10) (Fedora 1.88.0-1.fc42)
$ npm --version
10.9.2
$ python --version
Python 3.13.5
$ cat /etc/redhat-release 
Fedora release 42 (Adams)

Even I am on Silverblue I'd expect my system to be binary compatible with Fedora 42. Do you have an idea in which direction to poke? Thanks for keeping up the good work!

@goshansp It took me a while to come back to this, but I'm thankful for your last comment because I was able to reproduce the license error that you mentioned:

💥 maturin failed
  Caused by: license file `/home/<username>/sdk-sm/LICENSE` exists outside of the project root `/home/<username>/sdk-sm/languages/python`
  Caused by: prefix not found

I'm able to reproduce that, and the segfault you mentioned on Fedora Workstation 42 (Silverblue images weren't available with my cloud provider), so whatever is happening doesn't seem to be unique to Silverblue 🤔

@tangowithfoxtrot thank you for reproducing the issues. I'd be happy to test any fixes. May we assume that sdk-sm is currently broken for all or many Linux distros? Are your checks only testing the build process without testing for segfault? If you have means to escalate this - I think the fix is highly anticipated within the community and will supercharge adoption. If you have ideas how I can help, please let me know.

I've initially failed at building those branches on Ubuntu 22 (node too old, syntax error) and Ubuntu 24 (Error is imported redundantly) ... Are we safe to assume that sdk-sm does not build on Linux at the moment? I am fiddling on my fork and I am building this now on Ubuntu 24 without getting the later import segfault. Next I want to understand why Fedora is nok.

Ubuntu 24 build system info

$ uname -a
Linux ubuntu-24 6.8.0-63-generic #66-Ubuntu SMP PREEMPT_DYNAMIC Fri Jun 13 20:25:30 UTC 2025 x86_64 x86_64 x86_64 GNU/Linux
$ cargo --version
cargo 1.75.0
$ npm --version
9.2.0
$ python --version
Python 3.12.3
$ lsb_release 
No LSB modules are available.
$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description:    Ubuntu 24.04.2 LTS
Release:        24.04
Codename:       noble
$ python -c "import bitwarden_sdk"
$ # No Segfault!

Differences between ok Fedora 41 and nok Fedora 42

ok: fedora 41
cargo 1.88
npm 10.9.2
python 3.13.2

nok: fedora 42
cargo 1.88
npm 10.9.2
python 3.13.5

I question if we'll be able to do this without the company assigning the Linux topic a higher priority.

EDIT: I am only getting the segfault when building on Fedora 42. There must be something different between Fedora 41 and Fedora 42 which we haven't checked yet.

EDIT2: Segfault only happens with maturin develop. When I do maturin build --release there is no segfault and it works as expected.

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

@goshansp, thanks again for your effort in looking into this. I don't exactly have an answer yet for where the issue lies that is causing the segfaults on some Linux environments (although, I suspect you are on the right track in your fork).

Since the segfaults that you're experiencing appear to be a separate issue from this PR, I opened a separate issue so we can track this as its own distinct bug. I believe that I've condensed as much of this conversation as I can into the ticket body there, but if you think I'm lacking any crucial info, we can continue our conversation about the segfaults there.

Merging this, as it fixes the original issue (the missing license file).

Thanks, @davzoku!