MPlayer 1.5 Released To Advance This Open-Source Video Player

[ssokolow]

I would assume that if there would be wide spread hacks via video files played on players we would know about it?

Actually, it's quite reasonable. The Android libstagefright vulnerability. Thumbnailers setting up a browser-esque sandboxing architecture... File format parsers/decoders written in memory-unsafe languages are a very juicy target... especially when you're targeting something that needs parsers for potentially dozens of file formats and you only need to find one vulnerability.

Sounds a bit to me like the story that china placed some microscopic chips inside some IT Hardware which seems to be not happend in the case they talked about it in the end.

The "microscopic chips" were the normal flash memory chips that hold the firmware. The claim was that China was patching backdoors into the UEFI firmware of server motherboards, piggy-backing on the code that already needs to be in there for remote management support.

[xhustler]

And I want a media player with a nice simple gui and not the ugly mess that is MPlayer. Yes I know it can be themed but the current themes are horrible as well.

[blackiwid]

Actually, it's quite reasonable.

Again if it would be wide spread we would know of actual cases, that go beyond a proof of concept demonstration. Therefor it's not quite reasonable that it's used wide spead currently.

The "microscopic chips" were the normal flash memory chips that hold the firmware. The claim was that China was patching backdoors into the UEFI firmware of server motherboards, piggy-backing on the code that already needs to be in there for remote management support.

That people use technics to have backdoors is not the same as the specific example I told about installing microscopig chips:
https://www.wired.com/story/plant-sp...of-of-concept/

That you talk here so specificly about china is strange to me, because of course every smartphone has a NSA Backdoor in the Modem operation System (the OS is the backdoor) that has access in 99.9% of the cases to the full Ram, and can send as modem data if requested or according to some patterns depending on how they set it up exactly.

And the US is more likely to have power to hurt me as german citizen as china does... They could plant fake proof or just send the police to me because I ordered weed or something...

All I do is opensource so I am less worried about them. Also if the west would want to get rid of backdoors in UEFI Firmware there would be a easy solution, just all oems starting with Apple but other players would be able to do it like Lenovo to Libreboot and there would be no room to hide backdoors anymore. So the West / Companies / Government has no problem with antifeatures in UEFIs... at least if that is the price to have the vessel to plant their own backdoors, too.

[Jabberwocky]

Firejail uses the same cgroups-based sandboxing as Flatpak, but with less strict containment, because it can't rely on the application only depending on the libraries it either bundles or gets from the provided application runtime. (Seriously. Firejail's --whitelist only affects $HOME and, if you want to whitelist anything outside there.. such as a /mnt path that your user has write access to, you need to manually build up an equivalent list of --blacklist calls.)

Also, that MPV profile isn't as strict as what I laid out with Flatpak even with host:ro instead of the XDG portal system.

Heck, Flatpak uses its own equivalent to Firejail called Bubblewrap... though Bubblewrap presents a lower-level, more limited API and expects you to use it in concert with other tools, while Firejail bundles equivalents to a bunch of Flatpak components into a single binary with a higher-level API.

My approach is to use Flatpak for open-source applications and Firejail for GOG.com games.

You're right. One just needs to verify that Bubblewrap is being used with Flatpak as it's two separate projects.

[ssokolow]

That people use technics to have backdoors is not the same as the specific example I told about installing microscopig chips:
https://www.wired.com/story/plant-sp...of-of-concept/

That you talk here so specificly about china is strange to me, because of course every smartphone has a NSA Backdoor in the Modem operation System (the OS is the backdoor) that has access in 99.9% of the cases to the full Ram, and can send as modem data if requested or according to some patterns depending on how they set it up exactly.

Yeah, I remember that article. I'm talking about China because that was what was in the follow-ups to that specific article that I read.

[skeevy420]

And I want a media player with a nice simple gui and not the ugly mess that is MPlayer. Yes I know it can be themed but the current themes are horrible as well.

I'm partial to SMPlayer with the Breeze Dark scheme.

[ssokolow]

You're right. One just needs to verify that Bubblewrap is being used with Flatpak as it's two separate projects.

I could be wrong, but I was under the impression that Bubblewrap was an integral part of how Flatpak sets up the container that virtualizes /usr to bind the running application to the Freedesktop/GNOME/KDE runtime image it was built against.

if that's true, then it's sort of like saying "One just needs to verify that Linux is being used with Bubblewrap, as they're two separate projects"... as far as I know, the cgroups API hasn't been ported to any other kernels yet and Bubblewrap is a cgroups frontend that got split out of Flatpak with the intent that others could use it too.

[danboid]

Its been a very long time since I installed or used mplayer.

Could someone please explain what advantage, if any, it has over mpv for those who don't care about a GUI?

[RahulSundaram]

I could be wrong, but I was under the impression that Bubblewrap was an integral part of how Flatpak sets up the container that virtualizes /usr to bind the running application to the Freedesktop/GNOME/KDE runtime image it was built against.

if that's true, then it's sort of like saying "One just needs to verify that Linux is being used with Bubblewrap, as they're two separate projects"... as far as I know, the cgroups API hasn't been ported to any other kernels yet and Bubblewrap is a cgroups frontend that got split out of Flatpak with the intent that others could use it too.

This is all correct, I suspect the OP meant that not all Flatpaks use a restricted sandbox permissions by default and at the moment, it is not safe to assume that. You will have to use the cli or a dedicated app like Flatseal to validate and tweak it according to your requirements.

[ssokolow]

This is all correct, I suspect the OP meant that not all Flatpaks use a restricted sandbox permissions by default and at the moment, it is not safe to assume that. You will have to use the cli or a dedicated app like Flatseal to validate and tweak it according to your requirements.

Of course, but I find that to be much less of a hassle than using Firejail. With Firejail, it's necessary to make sure that all methods of invoking the application have been properly redirected through it. With Flatpak packages, you have to go through flatpak run and the build and installation process handle redirecting everything through flatpak run, the portal-based version of xdg-open provided by the Runtime, and the chosen Runtime, so the irritating part is done and I can just flatpak override or Flatseal comfortably.

Even GOG.com games, with their bundled libraries, still have dependencies on the system libraries that Flatpak avoids the sandboxing complexity for by mounting its own runtime image over /usr... though, granted, that does break MakeHuman's integration with Flatpak'd Blender, because its IPC protocol is designed to assume that Blender can see the textures it installed in /usr/share/makehuman-community rather than passing them over the IPC.