Flatpak Playback Failed

[OdinVex]

Jellyfin via Web Client works fine, but Flatpak just fails. FFMPEG is fussing about my certificate (which is trusted by host and is also manually added into all browsers, as well as their configurations being set to use system trust store). Jellyfin, like most of all software on Flatpak, needs to be updated to allow trusting the host/system certificate stores.

Error in logs: ffmpeg: tls: Peer certificate failed verification.

• Version 1.7.1 Stable

[OdinVex]

And no, ignoring SSL errors is not a valid response to this, this is a certificate installed by Organization and should be trusted, not simply ignored. Ignoring SSL errors ignores all.

[lbrunkho]

Confirmed this is also preventing playback for me.
2023-01-30 16:37:11 [ ERROR ] PlayerComponent.cpp @ 594 - ffmpeg: tls: Peer certificate failed verification
I've been building / installing JMP from the system package manager as a work arround but I would like the flatpak to work as well.

[OdinVex]

Confirmed this is also preventing playback for me. 2023-01-30 16:37:11 [ ERROR ] PlayerComponent.cpp @ 594 - ffmpeg: tls: Peer certificate failed verification I've been building / installing JMP from the system package manager as a work arround but I would like the flatpak to work as well.

Apparently this is a widespread Flatcrap issue. Flatcrap's ****ty policies of sandboxing has resulted in an absolutely huge amount of software unable to use system-store certificates. Most 'solutions' are terrible work-arounds or migrations to specific libraries capable of punching through the catbox (crappy sandbox). (I hate AppImage/Flatpak/Snap, ton of reasons, this is another peeve.)

[lbrunkho]

I agree, flatpak was growing on me at first but at this point I'm moving away from using it because of the non-stop issues I'm having with my system-store certs (amongst other reasons). I have been using fedora on my laptop to try and widen my Linux horizons so it looks like I'm going to be building JMP as there is no rpm binary available and the JMP flatpak is just broken.

[b-m-f]

flatpak/flatpak#2721

Maybe this will help to fix this

[OdinVex]

flatpak/flatpak#2721

Maybe this will help to fix this

I moved to Arch-based distros, no more problems with Flatcrap, AUR fixes all. Edit: The one post tries to push it off as 'app developer' issue instead of Flatkrap's catboxing. *eyeroll* Software shouldn't even be restricted from the host filesystem. Flatkrap should have been nothing but a flexible ABI with helpers at most.

[b-m-f]

Well, whatever the case may be, I still have it installed right now and would like a clean fix.

Unfortunately I can not find where the flatpak package is being build in this repository.
@iwalton3 are you pushing it to flathub manually?

[b-m-f]

Ok. Found it at https://github.com/flathub/com.github.iwalton3.jellyfin-media-player/blob/master/com.github.iwalton3.jellyfin-media-player.json .

I'll give it a look

[b-m-f]

I am going to keep dumping more info here for later use:

The ignore flag is evaluated here:

jellyfin-media-player/src/player/PlayerComponent.cpp

Line 133 in 721e84f

if (SettingsComponent::Get().ignoreSSLErrors()) {

Next step

• Figure out where mpv is looking for certs. Maybe it can be configured to include most known certificate locations.
• try it it works with access to host dirs.

[iwalton3]

@iwalton3 are you pushing it to flathub manually?

Looks like you found the repo. I don't have any CI automation for creating Flatpak releases but it basically is just a commit reference.

[b-m-f]

The issue seems to be here

jellyfin-media-player/src/player/PlayerComponent.cpp

Line 137 in 721e84f

#if !defined(Q_OS_WIN) && !defined(Q_OS_MAC)

.

Instead of relying on either gnutls ( which is compiled into ffmpeg), or openssl (which could also be compiled into ffmpeg -> I tried, didnt help) to provide access to https://p11-glue.github.io/p11-glue/p11-kit/manual/index.html the hardcoded paths are being searched.

Since you will find the default trust-stores from the runtime on those, they will simply be used, meaning that big CA's are still trusted, but custom ones will be ignored.

Long term this could lead to more and more problems as CA information becomes stale.

I will try to compile a version that does not set the paths and simply activates tls_verify and will report back

[OdinVex]

The issue seems to be here

jellyfin-media-player/src/player/PlayerComponent.cpp

Line 137 in 721e84f

#if !defined(Q_OS_WIN) && !defined(Q_OS_MAC)

.

Instead of relying on either gnutls ( which is compiled into ffmpeg), or openssl (which could also be compiled into ffmpeg -> I tried, didnt help) to provide access to https://p11-glue.github.io/p11-glue/p11-kit/manual/index.html the hardcoded paths are being searched.

Since you will find the default trust-stores from the runtime on those, they will simply be used, meaning that big CA's are still trusted, but custom ones will be ignored.

Long term this could lead to more and more problems as CA information becomes stale.

I will try to compile a version that does not set the paths and simply activates tls_verify and will report back

Google Play requires no tampering of validation functions, but you can give users the ability to add/remove certs or trust the System Store. I don't see why cert-importing/trusting isn't added. “Recognize this thumbprint? Alright then, added the anchor(s)!”

[b-m-f]

The issue seems to be here

jellyfin-media-player/src/player/PlayerComponent.cpp

Line 137 in 721e84f

#if !defined(Q_OS_WIN) && !defined(Q_OS_MAC)

.
Instead of relying on either gnutls ( which is compiled into ffmpeg), or openssl (which could also be compiled into ffmpeg -> I tried, didnt help) to provide access to https://p11-glue.github.io/p11-glue/p11-kit/manual/index.html the hardcoded paths are being searched.
Since you will find the default trust-stores from the runtime on those, they will simply be used, meaning that big CA's are still trusted, but custom ones will be ignored.
Long term this could lead to more and more problems as CA information becomes stale.
I will try to compile a version that does not set the paths and simply activates tls_verify and will report back

Google Play requires no tampering of validation functions, but you can give users the ability to add/remove certs or trust the System Store. I don't see why cert-importing/trusting isn't added. “Recognize this thumbprint? Alright then, added the anchor(s)!”

But why is Google relevant here?

@iwalton3 What I wrote above fixes the issues.
9901a9f
is the patch. Not setting those paths makes the underlying gnutls use the pkcs11 socket that is mounted inside the flatpak namespace.

Now, I do not know whether those paths are needed for old systems that do not support this setup yet.
In that case it might be wise to introduce a new configuration option -> use_legacy_certificates to search the paths instead of relying on the socket.

Let me know if this solution works for you and whether you would prefer to code this or rather have a PR against this repo.

[OdinVex]

But why is Google relevant here?

The problem applies to Android versions as well. Unless you use FDroid to get around Google's policy. (Essentially, the entire cert-validation backend that occurs is an issue for Android and Flatkrap. Flatkrap's is due to too much catboxxing and requiring developers to break out. Android's is about the fact that the System Store isn't trusted (same situation with Flatkrap, just different means of access).) Android's situation can't be “just trust any cert” because that's a poor fix and doesn't account for mitm unless you at least remember thumbprints and compare. The ability to specify certs (add/remove) coincidentally solves both Android and Flatkrap's issues, so that's an option. Just switching libraries or poking holes in Flatkrap doesn't solve Android's. Merely pointing out the breadth of it all.

[vonProteus]

any progress?
or walkaround?
this hit me recently on a steam deck
im on jellyfin-media-player 1.9.0
menu and selection screen works fine only playback doesn't works

and some logs which i think may be helpful

2023-04-22 22:09:17.951 [debug] unknown @ 0 - cplayer: Set property: vd="" -> 1
2023-04-22 22:09:17.951 [info] unknown @ 0 - Entering state: buffering
2023-04-22 22:09:17.952 [info] unknown @ 0 - JS: Active player: {"name":"MPV Video Player","id":"mpvvideoplayer","playerName":"MPV Video Player","playableMediaTypes":[false,true,false,false],"isLocalPlayer":true,"supportedCommands":["GoHome","GoToSettings","VolumeUp","VolumeDown","Mute","Unmute","ToggleMute","SetVolume","SetAudioStreamIndex","SetSubtitleStreamIndex","SetMaxStreamingBitrate","DisplayContent","GoToSearch","DisplayMessage","SetRepeatMode","SetShuffleQueue","PlayMediaSource","PlayTrailers","ToggleFullscreen","SetAspectRatio","PlaybackRate"]}
2023-04-22 22:09:17.952 [debug] unknown @ 0 - ffmpeg: Opening https://jellyfin.lan/Videos/xxxx/stream.mov?Static=true&mediaSourceId=xxxx&deviceId=xxxxI1&api_key=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx&Tag=xxxxx
2023-04-22 22:09:17.952 [info] unknown @ 0 - JS: SyncPlay WrapperFactory getWrapper: htmlvideoplayer
2023-04-22 22:09:17.956 [info] unknown @ 0 - JS: Requesting url without automatic networking: https://jellyfin.lan/Sessions/Playing
2023-04-22 22:09:17.957 [info] unknown @ 0 - JS: nowplaying event: playbackstart
2023-04-22 22:09:17.958 [info] unknown @ 0 - JS: nowplaying event: playbackstart
2023-04-22 22:09:18.189 [critical] unknown @ 0 - ffmpeg: tls: Peer certificate failed verification
2023-04-22 22:09:18.191 [critical] unknown @ 0 - stream: Failed to open https://jellyfin.lan/Videos/xxxxx/stream.mov?Static=true&mediaSourceId=xxxxxx&deviceId=xxxxxxI1&api_key=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx&Tag=xxxxx.
2023-04-22 22:09:18.191 [debug] unknown @ 0 - cplayer: Opening failed or was aborted: https://jellyfin.lan/Videos/xxxxx/stream.mov?Static=true&mediaSourceId=xxxxx&deviceId=xxxxI1&api_key=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx&Tag=xxxxx
2023-04-22 22:09:18.191 [debug] unknown @ 0 - cplayer: finished playback, loading failed (reason 4)
2023-04-22 22:09:18.191 [info] unknown @ 0 - cplayer:
2023-04-22 22:09:18.191 [info] unknown @ 0 - "Entering state: error (loading failed)"
2023-04-22 22:09:18.197 [info] unknown @ 0 - "DisplayManager found 1 Display(s)."
2023-04-22 22:09:18.197 [info] unknown @ 0 - "Available modes for Display #0 (DisplayPort-0)"
2023-04-22 22:09:18.197 [info] unknown @ 0 - "Mode  0:  3440 x 1440 x  0bpp @59.9726Hz"
2023-04-22 22:09:18.197 [info] unknown @ 0 - "Mode  1:  3440 x 1440 x  0bpp @99.9822Hz"

and i will add that on mac and iOS everything work as expected even on steam deck in firefox it works fine

[b-m-f]

I have posted the fix above and am just waiting for feedback from the maintainers.

[iwalton3]

https://jellyfin.lan/

So this is because you are trying to use a custom CA. I'll skip the usual disclaimer about how most clients don't support this and have no plans to...

What is surprising is that the QT WebEngine view works at all. I believe that historically has use Google Chrome's embedded trust store that you also have to edit, unless Flatpak patched it.

What I do need to make sure of is that we never have SSL validation fail for proper certificate authorities. The last version of MPV I used on Windows had the SSL authority hard-coded to a folder that didn't exist. (I should check that this is still the case now that I build it from source since upstream doesn't support TLS v3.) That's why there is the logic that tries to find the SSL authority instead of blindly trusting what is set.

What I would prefer to do is just add whatever authority Flatpak uses to that list OR run a check that verifies whatever is configured with ffmpeg actually exists. There is a reason Plex put that code here, and there is a strong chance that regular users who aren't using custom SSL certificate authorities (i.e. like 99 percent of users) could be affected if I remove it. MPV defaults to not checking SSL certificates, so we need to do some due diligence before enabling it.

[vonProteus]

so basically using custom root ca on server and adding it to all clients is unsupported
what about self signed certs? i presume that it is also not supported

[iwalton3]

Self signed is even less supported. I do not have any desire to manage certificate exceptions or custom CAs in my application manually.

I am willing to fix system CA support I just want to make sure it doesn't break anyone else.

[iwalton3]

You can of course disable certificate verification but that defeats most of the point of enabling SSL in the first place.

[vonProteus]

I am willing to fix system CA support I just want to make sure it doesn't break anyone else.

so in future release it can start working again?
I've been using this custom ca for a long time and had no problem until recently
and its sounds like problem is with installing my cert in correct cert store

it woks in curl for example

[iwalton3]

On Debian it works fine without a hard-coded SSL bundle, so I am just going to make the SSL cert bundle behavior optional and trust the system defaults. If anyone ends up having breakage as a result of this, you can use the autodetectCertBundle config option.

[vonProteus]

on steam deck witch custom root ca it is fixed in 1.9.1
so thank you ^_^

[Flightkick]

@iwalton3

On Debian it works fine without a hard-coded SSL bundle, so I am just going to make the SSL cert bundle behavior optional and trust the system defaults. If anyone ends up having breakage as a result of this, you can use the autodetectCertBundle config option.

Running a custom root CA which doesn't seem to work with Flatpak version 1.9.1 of Jellyfin Client on OpenSUSE Tumbleweed. The autodetectCertBundle flag in ~/.var/app/com.github.iwalton3.jellyfin-media-player/data/jellyfinmediaplayer/jellyfinmediaplayer.conf does not seem to make a difference.

Added both the root CA and intermediate certificate in PEM format to /usr/share/pki/trust/anchors/ and executed update-ca-certs, made sure that both signatures are present in /var/lib/ca-certificates/ca-bundle.pem.

The logs at ~/.var/app/com.github.iwalton3.jellyfin-media-player/data/jellyfinmediaplayer/logs/jellyfinmediaplayer.log still show certificate validation issues however:

2024-03-25 20:31:23.986 [debug] onCertificateError @ 221 - https://redacted.example.com/system/info/public :Server's certificate is not trusted.-202

I'm not sure if my system trust store is exposed within the Flatpak sandbox.
Maybe I'm missing something?

Systeminfo:
Operating System: openSUSE Tumbleweed 20240321
KDE Plasma Version: 6.0.2
KDE Frameworks Version: 6.0.0
Qt Version: 6.6.2
Kernel Version: 6.8.1-1-default (64-bit)
Graphics Platform: Wayland