The summary explains it all. Calls stuck on "exchanging encryption keys..." step and with video chats there is an endless loading. A similar issue is observed in RPM Fusion project: https://bugzilla.rpmfusion.org/show_bug.cgi?id=6616 There is also an upstream bug I filed with much more details: https://github.com/telegramdesktop/tdesktop/issues/26108 There are a lot of warnings of using deprecated functions when the Telegram is compiled. Perhaps, a warning may be displayed when it is compiled with OpenSSL 3, so that users know what their issues are caused by.
Thanks for the report. This is the age-old curse of linux, where we can't simply keep old libraries around and everything must succumb to the constant churn of updates. Sigh. I initially fixed the package to build with openssl 3 at all, and I was hoping upstream would eventually take the torch and fix up the deprecations and whatnot. This was a year and a half ago. Granted, I never tested this thoroughly, either. The deprecation warnings should be fine, the functions that cause these are still implemented for compatibility (thankfully), so they're not much more than mild annoyances. One can look for "OPENSSL_VERSION_NUMBER" in the source code, and make sure the compatibility changes make sense and are correct. I wonder if it's something to do with that. As for the gentoo package, I'd much rather pin the version requirement for openssl for the time being, but openssl is not SLOTed, making it a bit of a pain for anyone who wishes to use openssl 3 on their systems. Ugh.
More importantly, < OpenSSL 3 is EOL in September.
I made an important discovery — telegram-desktop is not at fault here. I reemerged `media-libs/tg_owt` with OpenSSL 1.1.1 (which itself was reemerged with `emerge -O`), after that telegram-desktop was recompiled with OpenSSL 3 and suddenly video chat started working (have not tested calls yet). This makes sense, as tg_owt is the WebRTC library tdesktop uses.
Can confirm that calls and video/audio chats even work on distribution's telegram-desktop (the one I __have not__ rebuilt after tg_owt was compiled with OpenSSL 1.1.1).
This is more of a `media-libs/tg_owt` bug, I suppose...
by the way, there is dev-libs/openssl-compat (which is not supposed to be built against, but can provide ossl:1 for proprietary/prebuilt packages built against it. Theoretically, we can make it to also contain headers (or make additional package with openssl-1.1 headers), and then build tg_owt with it (will require minor patching) Or we can temporary provide prebuilt tg_owt packages (built over ossl-1.1) with openssl-compat in DEPEND // or, as telegram upstream suggested, we can dive into webrtc sources and patch tg_owt to normally work with ossl3
Debugging tg_owt is the last thing I want to be doing, and I wouldn't wish it upon anyone else. It's always a nightmare, google has probably gotten webrtc working with openssl 3 already, and it's only a matter of time before upstream updates their copy of webrtc. The openssl-compat option sounds reasonable, I can just make a shadow pkgconfig dir so no patching is needed. Alternatively, openssl can be built statically for tg_owt. I'll wait a little longer to see what people are up to, but let me know if either of these options is desireable, and whether the issue is pressing enough to consider solutions like this.
It's not reasonable to try make network-heavy software use an outdated statically linked copy of 1.1.x which is soon EOL. This also applies to -compat which is purely for old binaries. That would put users at risk.
What should we do then? There are two ways to __solve__ with the problem (at least the ones I can think about). Them being either (1) fixing the tg_owt (which I can not do myself, not a programmer in the slightest) or (2) make it possible to use OpenSSL 1.1.1 headers and shared objects alongside OpenSSL 3 ones. The second option, as Sam James argued is not possible to achieve using available methods (OpenSSL-compat or static linking) without sacrificing securtiy. On a side note, is it possible to SLOT `dev-libs/openssl` and if so is it something which is worth doing?
(In reply to zurabid2016 from comment #9) > On a side note, is it possible to SLOT `dev-libs/openssl` and if so is it > something which is worth doing? Slotting would have the same anti-reasoning as using -compat, as it is pretty the same ( -compat builds the same ossl-1, but installs only libraries, skipping other stuff)
(In reply to Sam James from comment #8) > That would put users at risk. Yes, but that risk is kinda "accepted by telegram upstream", as they are doing the same in upstream-prebuilt versions (as well, as on flatpak/snap publishied versios). Moreover, even tdesktop upstream says, that they can't patch google's code (yes, google is actual upstream of the most code (webrtc) in tg_owt) as it is too hard to debug. So, what can we do, as we all have even less expertise in that? As I see, we have only two variants of what we can do: 1) hypotetically sacrifice security by linking tg_owt to ossl-1.1. 2) tell users to sit without a/v-calls on their desktop because of security.
Is there an upstream bug at telegram for the webrtc component being broken in tg_owt? Is there a bug with Google for webrtc? Ultimately anything not supporting openssl 3 in September will be masked and then removed.
I will file an upstream bug in tg_owt
There is a bug in telegram-desktop tracker (although, later it was discovered that problem's source is tg_owt: https://github.com/telegramdesktop/tdesktop/issues/26108
One absolutely wild emergency option is (and this would be a huge mess if any of tg_owt or telegrams deps link to openssl) could be to statically link libressl.
I suggest not to go **that** extreme. Specifying openssl-compat as a runtime dependency is a sufficient solution, which does not sacrifice on security (everyone still uses OpenSSL 1.1.1 as it is unkeyworded) **for now**. I will try my best to have this fixed upstream, but I make no promises
(In reply to Sam James from comment #12) > Ultimately anything not supporting openssl 3 in September will be masked and > then removed. What would we take as definition of "not supporting"? If we'll talk about "requires ossl-1 in runtime", then what about net-im/telegram-desktop-bin? It is linked (and, presumably, will be linked on september) over ossl-1 statically (so, all security issues can be applied to it too). If we'll talk about "should be able to build with ossl-3, then tg_owt won't be captured by that meaning, as it builds against openssl-3 kinda fine, and only have issues in runtime. (btw, I thought of renaming bug to handle new information that it is tg_owt's fault, but on the other hand, people who'll want to report a/v-calls issue on telegram (and not knowing the source of problem) may not see this issue in the list of possible duplicates, and will file duplicate. HDYT, should title be changed, or it'd be better to file new bug against tg_owt, and link it here?
Security critical applications like telegram-desktop-bin would likely be headed for the bin too.
(In reply to Sam James from comment #15) > One absolutely wild emergency option is (and this would be a huge mess if > any of tg_owt or telegrams deps link to openssl) could be to statically link > libressl. Actually, there **are** links against openssl both in other telegram deps, and even in telegram-desktop itself.
(In reply to Vadim A. Misbakh-Soloviov (mva) from comment #17) > HDYT, should title be changed, or it'd be better to file new bug against > tg_owt, and link it here? This bug certainly should be left as it is, since this is the only used package which is affected by the tg_owt not working properly and it is what people will search for when their experience the issue. I suggest creating a new bug specifically for tg_owt and CCing all the participants there.
(In reply to Sam James from comment #8) > It's not reasonable to try make network-heavy software use an outdated > statically linked copy of 1.1.x which is soon EOL. I don't want to make any sort of a stinker about this, but as a packager my primary concern is making sure the software is available and works. It's obviously bad to ship vulnerable software, but when there's no feature equivalent replacement, it doesn't seem entirely reasonable to drop an otherwise very actively maintained application that many people want to use. Unfortunately, Telegram Desktop isn't exactly a saint when it comes to security. Requiring an older version of openssl is a symptom of using a consistently out of date copy of google's webrtc, likely containing a significant amount of bugs that may or may not be exposed or exploitable in telegram proper, we cannot really know. As it stands, security-conscious users would be advised to steer clear from this or run it sandboxed. As this is an upstream choice, we cannot do much about it unless we take over development. For all the flak I throw at the telegram people, this situation isn't entirely their fault. Upgrading webrtc is a massive undertaking every time, and the situation with google not supporting global installations of webrtc, having everyone bundle this massive library separately instead, is very much less than ideal. As we're not the only distribution affected by this, maybe someone will create a fix, but in case this doesn't happen, I hope we can find a way to keep packaging this application. I'm going to need it for the time being.
What is the point of the argument? AFAIK OpenSSL 1.1.1t is and will still be maintained until September (and I am 99% sure it will have been fixed upstream by then) and it does nor have any known security vulnerabilities as of now. My suggestion is to use openssl-compat or anything else (whatever fits best), because there are (am I right on that?) no immediate security concerns.
(In reply to zurabid2016 from comment #22) > I am 99% sure it will have been fixed upstream by then Openssl 3 has been around for almost two years now, upstream hasn't cared to acknowledge it outside of accepting patches for it, and they don't have a great track record with caring about new compiler and library releases in general (again, they just accept volunteer patches). Maybe I'm overly pessimistic, maybe now it's become a runtime issue that affects various distributions someone will take a stab at it, but it's not impossible we'll hit the "deadline" without openssl3 support. That said, the main point of my argument was to highlight that this issue is a symptom of a bigger problem regarding webrtc in telegram. Even if someone fixes this, if packaging telegram with outdated libraries is considered a concern worthy of dropping it over, then telegram has, always has had, and always will have a big 'ol skeleton in its closet.
I filed a bug on tg_owt GitHub repo: https://github.com/desktop-app/tg_owt/issues/122
NB: 1) about "reported bug over tg_owt": https://github.com/telegramdesktop/tdesktop/issues/26108#issuecomment-1526377731 (upstream said that issue, opened in tdesktop repo is enough). 2) about webrtc in tg_owt. upstream said (in private telegram group): a) tg_owt already had upgraded webrtc to new versions with hope that google will fix openssl3 issue, but with no luck. Last upgrade was in December. And there is doubtful that current webrtc snapshot will have openssl3-compatibility changes. Especially in the case that google uses their own implementation, BoringSSL as preferred implementation. b) so there is not so much chances anything will be changed until september. c) Although, john-preston (main tdesktop developer) told me he'll try to dig into it, but no guaranties at all
Thanks for the context, I didn't realize google was the one not caring at this stage. I assumed that given chromium works fine with openssl3, so would webrtc. This makes sense, but it makes the situation slightly more awkward. I wonder how other webrtc users, like firefox, handle this? Do they have patches, or do they use boringssl? As an aside, I apologize if my prior comments seem dismissive of the telegram team's ongoing efforts. The webrtc situation isn't pretty for any of the parties involved. Thanks for looking into this.
A bit of "battlefield news": Current candidate to be guilty is libsrtp. john-preston tries to play with bumping it, and in case of success, he would try to make it a submodule (although, tg_owt still uses private APIs, so I'm not sure whether it will allow us to unbubdle it and use the system version)
A bit more news. It was exactly libsrtp fault, and when preston bumped it to the version used in chrome (and even further to 2.5) - calls become working again. So, fixes are coming. Although, "official builds" will probably still use 1.1 for now.
(In reply to Vadim A. Misbakh-Soloviov (mva) from comment #28) > It was exactly libsrtp fault, and when preston bumped it to the version used > in chrome (and even further to 2.5) - calls become working again. Considering that OpenSSL 3.0 was released in 2021 (source: https://en.m.wikipedia.org/wiki/OpenSSL) and libstrp has not been updated/bumped in tg_owt for **3 years** (which means it should have literally no support for OpenSSL 3) everything does really make sense esteve.varela@gmail.com, could you update tg_owt's ebuild, since changes have just been pushed upstream?
Interesting, I wonder if this'd be a good excuse to look into unbundling libsrtp again. Last I checked webrtc was using private APIs, making this a pain. I'll bump tg_owt asap, I won't be home for a day and it takes a bit on my machine so hold on tight.
libsrtp has been considered for unbundling again, but unfortunately google's code still accesses functions not exposed in the header, such as srtp_get_stream(). I will be doing a final bit of testing and submitting it.
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=37dc5b6a300e5962454809e39b17f2926ec3d82b commit 37dc5b6a300e5962454809e39b17f2926ec3d82b Author: Esteve Varela Colominas <esteve.varela@gmail.com> AuthorDate: 2023-04-30 20:11:40 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2023-05-07 07:21:41 +0000 net-im/telegram-desktop: Bump tg_owt version Closes: https://bugs.gentoo.org/905083 Thanks-to: <zurabid2016@gmail.com> Signed-off-by: Esteve Varela Colominas <esteve.varela@gmail.com> Closes: https://github.com/gentoo/gentoo/pull/30732 Signed-off-by: Sam James <sam@gentoo.org> .../telegram-desktop-4.6.5-r1.ebuild | 206 +++++++++++++++++++++ ...7.1.ebuild => telegram-desktop-4.7.1-r1.ebuild} | 2 +- ...8.1.ebuild => telegram-desktop-4.8.1-r1.ebuild} | 2 +- 3 files changed, 208 insertions(+), 2 deletions(-)
Can verify that the **issue is gone** (calls and video chats work when both packages are compiled with OpenSSL 3) as of following versions of tg_owt and telegram_desktop: [ebuild R ~] media-libs/tg_owt-0_pre20230428:0/20230428::gentoo USE="X screencast" 0 KiB [ebuild R ~] net-im/telegram-desktop-4.8.1-r1::gentoo USE="X dbus fonts (jemalloc) qt6 qt6-imageformats screencast wayland -enchant" 0 KiB
