You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
PR #782 landed mbedTLS 4 (PSA Crypto) support on main, which has since been renamed to libsrtp3 (v3.0.0). The 2.x line on 2_x_dev stayed on the legacy <mbedtls/aes.h> / <mbedtls/gcm.h> path, so v2.8.0 and later 2.x consumers still cannot build against mbedTLS 4.
This is starting to bite for the embedded / IoT world: ESP-IDF v6 (currently in pre-release, GA imminent) ships mbedTLS 4 by default. Anything still on the libsrtp 2.x line — and that's the mainstream of WebRTC consumers today, including the AWS Kinesis Video Streams C SDK — can't compile against IDF v6.
Question
What is the project's position on backporting PSA Crypto / mbedTLS 4 support to 2_x_dev?
Specifically:
Is 2_x_dev considered feature-frozen (security fixes only), with 3.x expected as the migration path?
If a backport gated on MBEDTLS_VERSION_MAJOR >= 4 (or >= 3 for the full PSA path) is acceptable in principle, we'd be happy to send a PR. A direct cherry-pick of mbedtls files changed and cmake instruction added to support MbedTLS … #782 isn't clean — the 3.x release also changed the internal cipher signature (in-place → src/dst buffers), so the backport needs adaptation to keep the 2.x cipher API intact for existing consumers.
Either answer is fine — we just want to know whether to invest the work or accept the v6 ceiling on the 2.x line.
Happy to share the conflict list and a backport sketch if it helps the conversation.
Context
PR #782 landed mbedTLS 4 (PSA Crypto) support on
main, which has since been renamed to libsrtp3 (v3.0.0). The 2.x line on2_x_devstayed on the legacy<mbedtls/aes.h>/<mbedtls/gcm.h>path, so v2.8.0 and later 2.x consumers still cannot build against mbedTLS 4.This is starting to bite for the embedded / IoT world: ESP-IDF v6 (currently in pre-release, GA imminent) ships mbedTLS 4 by default. Anything still on the libsrtp 2.x line — and that's the mainstream of WebRTC consumers today, including the AWS Kinesis Video Streams C SDK — can't compile against IDF v6.
Question
What is the project's position on backporting PSA Crypto / mbedTLS 4 support to
2_x_dev?Specifically:
2_x_devconsidered feature-frozen (security fixes only), with 3.x expected as the migration path?MBEDTLS_VERSION_MAJOR >= 4(or>= 3for the full PSA path) is acceptable in principle, we'd be happy to send a PR. A direct cherry-pick of mbedtls files changed and cmake instruction added to support MbedTLS … #782 isn't clean — the 3.x release also changed the internal cipher signature (in-place → src/dst buffers), so the backport needs adaptation to keep the 2.x cipher API intact for existing consumers.Either answer is fine — we just want to know whether to invest the work or accept the v6 ceiling on the 2.x line.
Happy to share the conflict list and a backport sketch if it helps the conversation.