#866784 libsrtp2-dev: Missing includes

Package:
libsrtp2-dev
Source:
libsrtp2
Description:
Secure RTP (SRTP) and UST Reference Implementations - development files
Submitter:
Sandro Knauß
Date:
2024-07-31 05:39:05 UTC
Severity:
normal
Tags:
#866784#5
Date:
2017-07-01 17:33:47 UTC
From:
To:
Package: libsrtp2-dev
Version: 2.1.0-1
Severity: normal
Control: affects -1 qtwebengine-opensource-src

Hey,

I tried to get rid of the internal copy of libsrtp2 in qtwebengine.
Unfortunably there is no srtp_priv.h,rtp.h and rtp_priv.h in /usr/include/srtp2
and I can't replace the copy, cause other parts depending on parts in the private
header.

Best Regrads,

sandro
#866784#12
Date:
2017-07-01 18:07:50 UTC
From:
To:
Hi Sandro,

Quoting Sandro Knauß (2017-07-01 19:33:47)

I am quite in favor of getting rid of code copies, but using on a
private library sounds like abuse which should be solved by either
rewriting/patching the project to only use public headers, or convince
the libsrtp project to make those private headers public.

I can forward this issue to the upstream developers of libsrtp, but will
then need some more substantial arguments why headers deliberately made
private should be made public. Even better if you get in touch with
upstream directly, as you can no doubt explain your needs better than me
acting as proxy.


 - Jonas
#866784#17
Date:
2017-07-01 19:34:47 UTC
From:
To:
Hey Jonas,

Well qtwebengine is a embeded browser (chromium) and needs the private headers
to build webrtc. Keep in mind also chromium is normally affected by issues,
that are stopping qtwebengine to use system packages (see as example #812091).

We had no issue to use system libsrtp-dev, because this had shipped the
private header.

I know shipping private header stuff is not ideal. But I prefer no copies and
one more transition if private stuff changes. Sorry but I have nor real indeep
knowlege, why webrtc needs the private stuff. I hope the surroundings are
enough to start the discussion with upstream.

Btw. upstream(qt) tells actually that qtwebengine using an non released
version of libsrtp (https://bugreports.qt.io/browse/QTBUG-60970)

As I don't know libsrtp it may be better if you start the discussion. I can
join afterwards. Otherwise you should discribe me, how to reach them properly.

Best Regards,

sandro
#866784#22
Date:
2017-07-01 20:46:27 UTC
From:
To:
Quoting Sandro Knauß (2017-07-01 21:34:47)

Sorry, but with that (lack of) reasoning for needing headers which
upstream has chosen to treat as private, I will not act as proxy.

Upstream preferred form of contact can be found in the Debian copyright
file: https://github.com/cisco/libsrtp/issues

 - Jonas
#866784#27
Date:
2018-06-01 11:00:44 UTC
From:
To:
Excerpts from Jonas Smedegaard's message of juli 1, 2017 10:46 pm:

You might also want to read bug#804545, which I suspect is either
directly related to this issue or if not then reasoning for being
cautious similar.

 - Jonas
#866784#34
Date:
2021-04-09 17:55:55 UTC
From:
To:
Hi all,

I opened the bug for this upstream, we have the same problem in reSIProcate

https://github.com/cisco/libsrtp/issues/532

Regards,

Daniel
#866784#39
Date:
2023-06-14 00:20:52 UTC
From:
To:
I would like to try to work to get this bug fixed.  I understand that it a
fairly heavy mountain to move and will involve coordination with various
upstreams (libsrtp, chromium, qtwebengine) as well as the packagers of those
programs, but I have a strong desire to get the Qt WebEngine packages in
Debian into good shape and am willing to invest time into this bug to see if
an acceptable solution can be found.

For those who have more experience with the history of this problem, do you
have any suggestions as to where I should start?
#866784#44
Date:
2023-06-14 04:39:55 UTC
From:
To:
Quoting Soren Stoutner via Pkg-voip-maintainers (2023-06-14 02:20:52)

Thanks for your interest in this issue!

I suggest - as also described in my previous emails here, to try patch
the Qt WebEngine code to get randomness elsewhere, because libsrtp was
not intented to provide that functionality and therefore the removal of
that private interface was deliberate.

Kind regards,

 - Jonas
#866784#49
Date:
2023-06-14 06:45:29 UTC
From:
To:
Thanks for the pointer.  I will start there and report back to this bug report
any progress I make.
#866784#54
Date:
2023-06-16 18:00:07 UTC
From:
To:
I decided to start by filing a bug report with Google and politely ask if they
would do the heavy lifting.

https://bugs.chromium.org/p/chromium/issues/detail?id=1455478[1]

It is a long shot, but sometimes you never know what you will get until you ask.

--------
[1] https://bugs.chromium.org/p/chromium/issues/detail?id=1455478
#866784#59
Date:
2024-07-23 17:49:57 UTC
From:
To:
Google is making some progress on this issue.

https://webrtc-review.googlesource.com/c/src/+/357543[1]

They still need to sort out the usage in:

third_party/webrtc/pc/srtp_session.cc

--------
[1] https://webrtc-review.googlesource.com/c/src/+/357543
#866784#64
Date:
2024-07-31 03:01:23 UTC
From:
To:
There is an upstream discussion about this with the libsrtp developers.

https://github.com/cisco/libsrtp/issues/721
#866784#69
Date:
2024-07-31 05:34:42 UTC
From:
To:
Quoting Soren Stoutner (2024-07-31 05:01:23)

Thanks for working on this, Søren.

 - Jonas