So, I am not going to deny that those security issues exist, but it seems like they would only pop-up in niche situations, or only if someone already had access to your admin profile. Most people are using Jellyfin to share their media with themselves and their tech-illiterate friends in family. In that use case, the only people who even know my server URL are people I have shared that info with privately. Nobody is trying to hack my admin account.
Now, I am no infosec expert. Maybe there are folks that are trying to run larger operations, and for those people I can understand why these security issues may become concerning if you don’t have a tight handle on the circle of people that have access to your server. That said, it’s also a bit silly to expect a free, open source solution to meet your needs in that scenario, anyway. If you know and understand the issues that well, then maybe go join the dev team and patch the holes. That is the beauty of open source, anyone can jump in and fix it.
The main issue there isn’t the fact that these issues exist. The problem is the Jellyfin devs attitude towards them, most of these problems have been known for years (more than five in some cases) but are largely ignored. Client compatibility is valued over everything else.
There have been plenty of suggestions, ideas and even PRs, but the devs priorities don’t allow for any security centered patches to get merged
idk the full history, but Joshua’s comment here does not give me the impression of devs that are just deliberately ignoring security issues. It seems like they are simply balancing priorities, which is what all good devs should do. Personally I like that client compatibility is valued over everything else - I would be pissed if they broke the Fire TV client to fix a minor security hole on a niche Linux distro, because then one of my users would be SOL. And as Joshua says in that comment:
many other options are now open to us in a post-10.11 landscape now that we have a proper library database ready.
So it seems like now they are better set up to address the security issues without breaking compatibility.
There are ways to fix these issues while preserving legacy client support. And honestly I don’t see how changing their database mess would help in solving security issues. In the end they’ll have to change their API to a more secure one, which will definitely disrupt client support for future updates
https://github.com/jellyfin/jellyfin/issues/5415
So, I am not going to deny that those security issues exist, but it seems like they would only pop-up in niche situations, or only if someone already had access to your admin profile. Most people are using Jellyfin to share their media with themselves and their tech-illiterate friends in family. In that use case, the only people who even know my server URL are people I have shared that info with privately. Nobody is trying to hack my admin account.
Now, I am no infosec expert. Maybe there are folks that are trying to run larger operations, and for those people I can understand why these security issues may become concerning if you don’t have a tight handle on the circle of people that have access to your server. That said, it’s also a bit silly to expect a free, open source solution to meet your needs in that scenario, anyway. If you know and understand the issues that well, then maybe go join the dev team and patch the holes. That is the beauty of open source, anyone can jump in and fix it.
The main issue there isn’t the fact that these issues exist. The problem is the Jellyfin devs attitude towards them, most of these problems have been known for years (more than five in some cases) but are largely ignored. Client compatibility is valued over everything else.
There have been plenty of suggestions, ideas and even PRs, but the devs priorities don’t allow for any security centered patches to get merged
idk the full history, but Joshua’s comment here does not give me the impression of devs that are just deliberately ignoring security issues. It seems like they are simply balancing priorities, which is what all good devs should do. Personally I like that client compatibility is valued over everything else - I would be pissed if they broke the Fire TV client to fix a minor security hole on a niche Linux distro, because then one of my users would be SOL. And as Joshua says in that comment:
So it seems like now they are better set up to address the security issues without breaking compatibility.
There are ways to fix these issues while preserving legacy client support. And honestly I don’t see how changing their database mess would help in solving security issues. In the end they’ll have to change their API to a more secure one, which will definitely disrupt client support for future updates