i feel like one issue is a bit of a downplay here, considering that it’s 12 different issues being shown as one mega issue. but yes that has most of them
But that’s also the most recent version of it. Some of those issues that they have listed there has had previous issues that were closed to be consolidated into that mega issue, which then was closed to be split into their own issues again.
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.
i feel like one issue is a bit of a downplay here, considering that it’s 12 different issues being shown as one mega issue. but yes that has most of them
But that’s also the most recent version of it. Some of those issues that they have listed there has had previous issues that were closed to be consolidated into that mega issue, which then was closed to be split into their own issues again.
But how does it matter if the issue is closed or open? It is linked and stated early and tracked.
That issues get merged and closed is quite normal when there arw duplicates.
Also, i think the oppoaite. The issues get ‘upplayed’. Which one of these are you actually worried about? And how does they affrct you?
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.