feat: native TLS by roderickvd · Pull Request #1541 · librespot-org/librespot

roderickvd · 2025-08-15T10:42:04Z

Maybe we're lucky and the latest Rust ecosystem is allowing us to switch to native TLS easily.
This PR switches from rustls and ring to native TLS on all platforms.

Fixes #1158

photovoltex · 2025-08-15T11:52:49Z

Do you know of act? I can highly recommend it if you have to debug the ci/cross-compile section. For it to work with act you have to make some adjustments found here dev...photovoltex:librespot:add-stages-for-act (maybe you also had to use a different image, I can't remember quite anymore tho).

- Split workflows into focused files (quality, cross-compile, build) - Replace manual SSL setup with rust-cross action for ARM/RISC-V builds - Consolidate Linux/Windows testing into single matrix job - Switch to specialized rust-cache and best-practice actions - Simplify clippy strategy to single comprehensive command - Add debug artifact publishing for all platforms - Fix YAML lint issues and improve formatting - Remove workflow dependencies for parallel execution

roderickvd · 2025-08-15T16:49:10Z

Do you know of act? I can highly recommend it if you have to debug the ci/cross-compile section.

I didn't and that does sound worth looking into to.

As you can see, going down the rabbit hole now... opportunistically refactoring the workflow definitions too.

If and when this passes, question is: do we want to always rely on native TLS? Or do we want to have features to opt for something else too? As commented here, when you go for any form of rustls today, then you will automatically get webpki bundled through hyper-proxy2.

photovoltex · 2025-08-15T18:25:50Z

As you can see, going down the rabbit hole now...

Thanks for looking into that, tho I can fully understand the initial decision to use webpki instead of native.

Looking back at some changes around the topic I found #1402. So we probably still need to provide a alternative with webpki. I would probably go for a feature instead of conditional compilation as this should be an explicit choice.

roderickvd · 2025-08-15T19:14:10Z

Yeah. And besides choice and explicitness I think I’m going to stop fighting the CI for Ubuntu not providing libssl-dev on these architectures.

So probably a feature flag native-tls (default) and rustls-tls-webpki-roots and that’s it until hyper-proxy2 is fixed.

RafaelKa · 2025-08-18T17:10:52Z

Hey,
it's nice to deploy the binaries as artifacts to the pull request builds via GH actions.

I know about the WIP state, but I tried to test it anyway.
I'm searching for a workaround for Moode-Player issue with Spotify
moode-player/moode#718

I downloaded and unzipped the artifacts "librespot-linux-aarch64-1.85" and "librespot-linux-aarch64-stable" from https://github.com/librespot-org/librespot/actions/runs/17026346100
on Raspberry Pi.
Then I tried to call ./librespot --version for both bineries(stable and 1.85)
Both of binaries complaining about libraries:

./librespot: error while loading shared libraries: libssl.so.1.0.0: cannot open shared object file: No such file or directory

I tried to symlink the libs

ln -s libssl.so libssl.so.1.0.0
ln -s libcrypto.so libcrypto.so.1.0.0

But there is some hard dependency to deprecated versions 1.0.0 of libcrypto and libssl:

./librespot --version
./librespot: /lib/aarch64-linux-gnu/libcrypto.so.1.0.0: version `OPENSSL_1.0.0' not found (required by ./librespot)
./librespot: /lib/aarch64-linux-gnu/libcrypto.so.1.0.0: version `OPENSSL_1.0.2' not found (required by ./librespot)
./librespot: /lib/aarch64-linux-gnu/libssl.so.1.0.0: version `OPENSSL_1.0.2' not found (required by ./librespot)
./librespot: /lib/aarch64-linux-gnu/libssl.so.1.0.0: version `OPENSSL_1.0.0' not found (required by ./librespot)

roderickvd · 2025-08-18T17:18:58Z

This is one reason when we discussed before not to publish artifacts: we could be swamped with support requests for these kind of dynamic linking problems stemming from different distributions, versions, etcetera. Not a criticism to you @RafaelKa but a reminder why we might not want to do this.

RafaelKa · 2025-08-18T17:40:55Z

This is one reason when we discussed before not to publish artifacts: we could be swamped with support requests for these kind of dynamic linking problems stemming from different distributions, versions, etcetera. Not a criticism to you @RafaelKa but a reminder why we might not want to do this.

But you'll publish the artifacts/binaries to releases?

roderickvd · 2025-08-18T17:48:27Z

No, we’ve always left that to downstream distributions.

- Remove default features from core and oauth crates - Move compile-time feature checks from core to oauth - Update CI workflows to build with default features and clarify artifact names - Separate rustls-tls build for riscv64gc target in cross-compile workflow

- Split cargo-hack checks and clippy runs into separate steps for TLS options - Simplify artifact naming in cross-compile workflow - Update RISC-V target to use rustls-tls and remove OpenSSL steps

photovoltex · 2025-08-18T21:45:15Z

Btw. you still want that to include this in 0.7, right? Can you request my review if you are done with it, so I can take a final look?

roderickvd · 2025-08-18T21:49:32Z

Yes, that'd be great. I'll tag you when ready.

I may just have found a way to have default features in the workspace members after all... sorry not sorry for the major Cargo.toml overhauls 😄 but it may just be possible.

Move dependency paths and versions to workspace, update feature propagation, and clean up per-crate Cargo.toml files for consistency. This also enables default features for workspace members.

Copilot

Copilot encountered an error and was unable to review this pull request. You can try again by re-requesting a review.

photovoltex

Seems overall good, just some minor thoughts here and there that came up during review :)

roderickvd · 2025-08-19T20:46:34Z

I checked rustls-platform-verifier and it is needed as hyper-rustls feature. With that I believe this PR to be complete, so I'm gonna go and squash merge it.

…lt (librespot-org#1541) Add support for choosing between native-tls and rustls-tls backends through feature flags, with native-tls as the default for maximum platform compatibility. Key changes: - Add mutually exclusive native-tls and rustls-tls feature flags - Use conditional compilation to select TLS implementation - Configure rustls-tls with platform certificate verifier - Refactor to workspace-based dependency management - Update CI workflows with improved cross-compilation support - Add comprehensive TLS backend documentation The native-tls backend uses system TLS libraries (OpenSSL on Linux, Secure Transport on macOS, SChannel on Windows) while rustls-tls provides a pure Rust implementation with platform certificate stores.

roderickvd self-assigned this Aug 15, 2025

Copilot AI review requested due to automatic review settings August 15, 2025 10:42

roderickvd added dependencies refactoring labels Aug 15, 2025

This comment was marked as resolved.

Sign in to view

feat(deps): move to native TLS on all platforms

f09ab81

roderickvd force-pushed the feat/native-tls branch from a3e3017 to f09ab81 Compare August 15, 2025 11:07

roderickvd added 4 commits August 15, 2025 15:17

fix: update apt after dpkg architecture add

6dd9bad

fix: vendorize openssl on riscv64gc

28562c2

fix: vendorize openssl on riscv64gc

0b6de6a

roderickvd added 3 commits August 17, 2025 23:19

feat: native-tls and rustls-tls features with rustls platform verifier

c092d23

fix: native-tls and rustls-tls are mutually exclusive

c6cf191

ci: always include one tls backend

4fd9db1

photovoltex reviewed Aug 18, 2025

View reviewed changes

Comment thread oauth/src/lib.rs

Comment thread core/Cargo.toml Outdated

Comment thread core/Cargo.toml Outdated

Comment thread core/src/http_client.rs

Comment thread .github/workflows/quality.yml

roderickvd added 7 commits August 18, 2025 22:01

refactor: document TLS backend options and propagate workspace fields

2103965

refactor: fix Rust 2024 clippy lints

279571f

chore: update deb package metadata and assets in Cargo.toml

901972f

fix: refactor CI workflows for Windows and update RISC-V config

f5b548d

- Split cargo-hack checks and clippy runs into separate steps for TLS options - Simplify artifact naming in cross-compile workflow - Update RISC-V target to use rustls-tls and remove OpenSSL steps

docs: clarify TLS feature validation location and rationale

7f692b4

refactor: remove webpki-tokio feature from hyper-rustls config

6e2f84f

style: cargo fmt

a892229

refactor: use workspace dependency management in Cargo.toml

3f476ad

Move dependency paths and versions to workspace, update feature propagation, and clean up per-crate Cargo.toml files for consistency. This also enables default features for workspace members.

roderickvd requested review from Copilot and photovoltex August 18, 2025 22:09

docs: minor wording change

37b5b6b

Copilot AI reviewed Aug 18, 2025

photovoltex reviewed Aug 19, 2025

View reviewed changes

Comment thread oauth/src/lib.rs

Comment thread core/Cargo.toml Outdated

Comment thread .github/workflows/cross-compile.yml

docs: update TLS backend selection in changelog

dbb4b8c

roderickvd merged commit 0a4969f into dev Aug 19, 2025
12 checks passed

roderickvd deleted the feat/native-tls branch August 19, 2025 21:06

robbiet480 mentioned this pull request Aug 21, 2025

No playback hassio-addons/app-spotify-connect#310

Closed

Conversation

roderickvd commented Aug 15, 2025

Uh oh!

This comment was marked as resolved.

Uh oh!

photovoltex commented Aug 15, 2025

Uh oh!

roderickvd commented Aug 15, 2025

Uh oh!

photovoltex commented Aug 15, 2025

Uh oh!

roderickvd commented Aug 15, 2025

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

RafaelKa commented Aug 18, 2025

Uh oh!

roderickvd commented Aug 18, 2025

Uh oh!

RafaelKa commented Aug 18, 2025

Uh oh!

roderickvd commented Aug 18, 2025

Uh oh!

photovoltex commented Aug 18, 2025

Uh oh!

roderickvd commented Aug 18, 2025

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

Uh oh!

photovoltex left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

roderickvd commented Aug 19, 2025

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

6 participants