Add riscv64 (linux_riscv64) wheel to PyPI releases

[gounthar]

Add linux_riscv64 wheel to PyPI releases

Summary

pip install cryptography on riscv64 Linux currently requires building from source (~8 min on a 1.6 GHz RISC-V SoC). Adding linux_riscv64 to the wheel build matrix would give riscv64 users a prebuilt wheel.

Evidence

Tested wheel	cryptography-46.0.5-cp313-abi3-linux_riscv64.whl
Hardware	BananaPi F3 (SpacemiT K1, rv64imafdcv, 8 cores @ 1.6 GHz, 16 GB RAM)
Python	3.13 (CPython)
Build system	custom (ghcr.io/pyca containers + Rust)
Build time	~8 min (native, on hardware)

The wheel imports and passes basic smoke tests on riscv64 Linux.

Suggested CI change

Workflow: .github/workflows/wheel-builder.yml

This is a multi-step change requiring infrastructure work:

1. Build a cryptography-manylinux_2_28:riscv64 container in pyca/infra
2. Cross-build static OpenSSL for riscv64 in pyca/infra
3. Add a MANYLINUX entry to wheel-builder.yml:

- NAME: manylinux_2_28_riscv64
  CONTAINER: cryptography-manylinux_2_28:riscv64
  RUNNER: ubuntu-latest

4. Add QEMU setup for the riscv64 runner

Note: This cannot be a simple one-line change. The infrastructure in pyca/infra must be updated first.

Ecosystem context

• manylinux_2_28_riscv64 images are available on quay.io/pypa/ (landed in pypa/manylinux, 2025)
• cibuildwheel 3.x supports riscv64 via QEMU emulation
• auditwheel supports riscv64 platform tags
• maturin-action supports riscv64gc-unknown-linux-gnu cross-compilation
• Packages already shipping riscv64 wheels on PyPI: aiohttp, yarl, regex, markupsafe, charset-normalizer, rpds-py, multidict, propcache, watchfiles, rignore, setproctitle
• RISC-V hardware is shipping: SiFive HiFive, SpacemiT K1/K3, Sophgo SG2044 (64-core)

Our temporary index

While upstream support is pending, we maintain a PEP 503 index with 50+ riscv64 wheels for the Python ML/AI stack, built natively on RISC-V hardware.

Tracking repo: https://github.com/gounthar/riscv64-python-wheels

[alex]

Please see https://cryptography.io/en/latest/faq/#will-you-upload-wheels-for-my-non-x86-non-arm64-cpu-architecture which documents our requirements to add support for a new architecture:

tl;dr; we need CI runners that can run tests on every PR with acceptable performance and stability.

[gounthar]

Thanks @alex for the pointer. That makes sense — reliability and performance of CI runners is key.

Two options that could help:

1. We have two BananaPi F3 boards (SpacemiT K1, 8 cores @ 1.6 GHz, 16 GB RAM, rv64imafdcv) already running as GitHub Actions self-hosted runners. We could register them for cryptography CI if that's useful.

2. The Cloud-V initiative provides cloud-based RISC-V CI infrastructure. They offer hosted RISC-V runners that could provide the stability and availability requirements you need without depending on individual hardware.

Would either of those work for your CI needs, or is there a specific runner setup / performance threshold you'd need to see first?

[alex]

In terms of performance/reliability, the minimums are roughly:

• A bare minimum of 3 concurrent jobs. (In practice I think even would probably be too low, but anything less isn't worth considering.)
• Able to run our tests jobs in <10 minutes.
• Runners need to run in stateless, ephemeral environments. So self hosted Github Actions runners can work well, but they need appropriate isolation.
• High availability, at least 2 9s.

[gounthar]

Thanks @alex for the concrete requirements.

3+ concurrent, <10 min, ephemeral, 99%+ availability; understood. For reference, our native build of cryptography on the F3 boards takes about 8 minutes, so the <10 min threshold is within reach on current hardware.

Another service that might help beyond the Cloud-V option I mentioned earlier: riscvrunners.com : a self-service RISC-V CI SaaS with a free emulated tier (3,000 min/month) and paid native hardware tiers. Might be quicker to evaluate since it's self-service.

Happy to help with evaluation if either path looks promising.

[alex]

We're an OSS project with no external funding, so a commercial RISC-V service is of limited use for us -- we rely on free services for our CI.

[reaperhulk]

To add to Alex's requirements: we have no interest in having to manage infrastructure or secondary CI systems, so it's effectively a requirement that someone else operate an ephemeral runner setup on the target architecture as a GitHub integration that we can use and provide it free of charge. An example of an org that has successfully done this is IBM with ppc64le: https://github.com/IBM/actionspz