[GH-ISSUE #1158] Add support for native tls #532

New issue

Closed

opened 2026-02-27 19:31:09 +03:00 by kerem · 2 comments

kerem commented

2026-02-27 19:31:09 +03:00

Owner

Originally created by @jirutka on GitHub (Apr 23, 2023).
Original GitHub issue: https://github.com/librespot-org/librespot/issues/1158

Can you please add support for native tls, i.e. allow linking against system-provided TLS library?

Rustls can't be built as a shared library, so it's always statically linked (bundled) into the application binary. So instead of having one system TLS library that can be independently patched for a vulnerability, you end up with who-knows-how-many binaries with different versions of the TLS library bundled inside. It doesn't matter if the library is written in C or Rust, it is still prone to various types of bugs, and in the case of a crypto library, they can lead to critical vulnerabilities. Also, rustls is not written purely in Rust, it is built on top of ring, which is written in assembly and C. Another problem is that ring only supports a limited set of CPU architectures (e.g. ppc64le is not supported).

Originally created by @jirutka on GitHub (Apr 23, 2023). Original GitHub issue: https://github.com/librespot-org/librespot/issues/1158 Can you please add support for native tls, i.e. allow linking against system-provided TLS library? Rustls can't be built as a shared library, so it's always statically linked (bundled) into the application binary. So instead of having one system TLS library that can be independently patched for a vulnerability, you end up with who-knows-how-many binaries with different versions of the TLS library bundled inside. It doesn't matter if the library is written in C or Rust, it is still prone to various types of bugs, and in the case of a crypto library, they can lead to critical vulnerabilities. Also, `rustls` is not written purely in Rust, it is built on top of [ring](https://github.com/briansmith/ring), which is written in assembly and C. Another problem is that `ring` only supports a limited set of CPU architectures (e.g. ppc64le is not supported).

kerem

2026-02-27 19:31:09 +03:00

closed this issue
added the
enhancement

dependencies
labels

kerem commented

2026-02-27 19:31:10 +03:00

Author

Owner

@roderickvd commented on GitHub (Apr 24, 2023):

Feel free to submit a PR. As with other project, let’s make it feature-gated to give users the choice.

@roderickvd commented on GitHub (Apr 24, 2023): Feel free to submit a PR. As with other project, let’s make it feature-gated to give users the choice.

kerem commented

2026-02-27 19:31:10 +03:00

Author

Owner

@roderickvd commented on GitHub (Aug 13, 2025):

Today via #1534 whatever native TLS support we had was removed in favor of just ring. Not because I don’t think we should have native TLS, but because AWS-LC and OpenSSL, and the way our dependencies have different ways of dealing with them, broke cross-compilation again after upgrading our dependency ecosystem.

As I want to focus my time on other things than cross-compilation, I continue to invite veterans in that field to put in a PR and maintain it.

@roderickvd commented on GitHub (Aug 13, 2025): Today via #1534 whatever native TLS support we had was removed in favor of just ring. Not because I don’t think we should have native TLS, but because AWS-LC and OpenSSL, and the way our dependencies have different ways of dealing with them, broke cross-compilation again after upgrading our dependency ecosystem. As I want to focus my time on other things than cross-compilation, I continue to invite veterans in that field to put in a PR and maintain it.

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

starred/librespot#532

No description provided.

Rows
Columns