Doesn’t it affect all of us in that we cannot safely run it exposed to the internet? I mean I still yolo it and run my jellyfin completely exposed because there’s no way I’m guiding anyone through setting up wire guard or configuring clients to do additional auth, but still. I would love to not worry about that.
How come this is not an issue for other projects then? Why isn’t Overseer also saying "don’t host this publicly because we can’t also can’t guarantee perfect security? Is the issue really just that they can’t prove security or is there an actual security issue with the API? From what you’re saying it sounds like the only issue is that they haven’t done an audit but that it’s otherwise fine, but other people are saying there are actual security holes regardless of whether an audit is performed.
Like, I’m fine running stuff publicly that hasn’t been audited like most of the stuff I self host. Why are people treating jellyfin differently than other self hosted projects that haven’t been audited?
I am saying that the mentioned security vulnerbility is not as big as ppm make it to be. The bad thing right now is that IF you know the exact path of a media item you can probe if its there. As soon as you varg your path by just single character from the default/guides that are out there, this is basically no longer practical.
Is this ok? No. But to fix this, every Client would be broken.
The current API dies not follow modern security practices since some are not or partially autheticated.
Thats basically inherited by Emby.
That is the current main issue and needs to be dealt with.
I assume that after the last EFcore (database handling) this gets addressed since now the API can be designed around the standerized databade calls.
Also overseer is also not saying “pls host on the public internet”. If you do so, you are on your own.
Why jellyfin gets treaded different? I do not know.
EDIT: I guess at least some ppl, use this as a comfortable excuse to stay on Plex. “But it is insecure… so i can not set it up”
Ok, well you just made it sound like the main issue was the lack of audit /guarantee and not an actual security issue. I don’t think breaking clients is an excuse not to at least get started putting forward a date, even if it’s a year in the future, where clients need to be updated by. Sure Overseeer isn’t begging people to put it on the internet, but there aren’t any known vulnerabilities to my knowledge, same with vaultwarden. Imo it’s a big win to getting more people comfortable using jellyfin if they can put their foot down and say clients need to update, or stay on the old version. Every time there’s Plex drama, it seems like the list of reasons people don’t want to spend time to migrate isn’t getting whittled down much. I’ve donated hundreds of dollars over the years at this point to jellyfin proper as well as several clients hoping things could move faster. Like imagine if the Overseeer devs designed a frontend. There’s nothing that jellyfin can’t technically do that I find missing, but it feels like a death by a thousand cuts.
Just because you do know any or that there are no know to the public does not mean it is secure. Do we know if the plex communication with your server is secure? No one cares, because no one is looking into it.
The main issue, is that ita not that simple to get new versions on the closed eco systems on many smart TV, especially when you are just a single dev and no company who can throw money on the problem.
As I said, the issue is not that big, and mainly an excuse for most ppl.
The API break will come, hopefully sooner than later, but it needs to be carefully designed, to prevent issues in the future.
But again, the current issue is not that much of a problem. I do not see the benefit of anyone to probe my server if i have certain media files on there. And i do not use the default paths.
Sure not knowing of an issue doesn’t mean it’s secure, but that doesn’t also mean that projects with known issues aren’t a problem… Like if you want jellyfin to be popular you should want this to be fixed - I don’t get this attitude from people who main jellyfin who seem opposed to pushing for it to be better. It not being a big issue is your own personal opinion - it’s obvious that known security issues sitting around for a long time bothers a lot of people so the sooner it gets addressed, the fewer reasons people have to stick with Plex. That’s a good thing right?
Doesn’t it affect all of us in that we cannot safely run it exposed to the internet? I mean I still yolo it and run my jellyfin completely exposed because there’s no way I’m guiding anyone through setting up wire guard or configuring clients to do additional auth, but still. I would love to not worry about that.
The question is, are the vulnerabilities actually a risk for your setup?
Should they be fixed? Absolutely.
But do they affect you? For me its basically a no.
A vulnability can be a nothing burger or critical issue that needa to be fixed. But it depends.
If it’s a nothing burger then they should come out and say it’s fine to run your instance publicly then
No, it is impossible to certify security, it’s only possible to certify insecurity.
They could only say something like “it’s designed to run exposed” or something like it.
You can pay for the audit if you like and still there would be no certainty.
I assume, before they say something like that they want a completely new API. But this would break every single client.
How come this is not an issue for other projects then? Why isn’t Overseer also saying "don’t host this publicly because we can’t also can’t guarantee perfect security? Is the issue really just that they can’t prove security or is there an actual security issue with the API? From what you’re saying it sounds like the only issue is that they haven’t done an audit but that it’s otherwise fine, but other people are saying there are actual security holes regardless of whether an audit is performed.
Like, I’m fine running stuff publicly that hasn’t been audited like most of the stuff I self host. Why are people treating jellyfin differently than other self hosted projects that haven’t been audited?
I am saying that the mentioned security vulnerbility is not as big as ppm make it to be. The bad thing right now is that IF you know the exact path of a media item you can probe if its there. As soon as you varg your path by just single character from the default/guides that are out there, this is basically no longer practical.
Is this ok? No. But to fix this, every Client would be broken.
The current API dies not follow modern security practices since some are not or partially autheticated. Thats basically inherited by Emby.
That is the current main issue and needs to be dealt with.
I assume that after the last EFcore (database handling) this gets addressed since now the API can be designed around the standerized databade calls.
Also overseer is also not saying “pls host on the public internet”. If you do so, you are on your own. Why jellyfin gets treaded different? I do not know.
EDIT: I guess at least some ppl, use this as a comfortable excuse to stay on Plex. “But it is insecure… so i can not set it up”
Ok, well you just made it sound like the main issue was the lack of audit /guarantee and not an actual security issue. I don’t think breaking clients is an excuse not to at least get started putting forward a date, even if it’s a year in the future, where clients need to be updated by. Sure Overseeer isn’t begging people to put it on the internet, but there aren’t any known vulnerabilities to my knowledge, same with vaultwarden. Imo it’s a big win to getting more people comfortable using jellyfin if they can put their foot down and say clients need to update, or stay on the old version. Every time there’s Plex drama, it seems like the list of reasons people don’t want to spend time to migrate isn’t getting whittled down much. I’ve donated hundreds of dollars over the years at this point to jellyfin proper as well as several clients hoping things could move faster. Like imagine if the Overseeer devs designed a frontend. There’s nothing that jellyfin can’t technically do that I find missing, but it feels like a death by a thousand cuts.
Just because you do know any or that there are no know to the public does not mean it is secure. Do we know if the plex communication with your server is secure? No one cares, because no one is looking into it.
The main issue, is that ita not that simple to get new versions on the closed eco systems on many smart TV, especially when you are just a single dev and no company who can throw money on the problem.
As I said, the issue is not that big, and mainly an excuse for most ppl. The API break will come, hopefully sooner than later, but it needs to be carefully designed, to prevent issues in the future.
But again, the current issue is not that much of a problem. I do not see the benefit of anyone to probe my server if i have certain media files on there. And i do not use the default paths.
Sure not knowing of an issue doesn’t mean it’s secure, but that doesn’t also mean that projects with known issues aren’t a problem… Like if you want jellyfin to be popular you should want this to be fixed - I don’t get this attitude from people who main jellyfin who seem opposed to pushing for it to be better. It not being a big issue is your own personal opinion - it’s obvious that known security issues sitting around for a long time bothers a lot of people so the sooner it gets addressed, the fewer reasons people have to stick with Plex. That’s a good thing right?