I’m not using Plex, but I feel like I can answer my complaints about using jellyfin.
My biggest complaint is the lack of clients. It is such a pain in the butt to install jellyFin on all of my products.
My second complaint is the security design. They’ve had open issues about unauthenticated endpoints for three or four years now. And whenever the issue gets so old that it starts to look bad, they refactor the issue into a newer issue abd bury it in the sand.
For a while this was done under the guise of maintaining legacy client support, but just recently it looks like they’re starting to focus on more security, and I’ve noticed some of those security holes are being closed finally, but it’s a major concern for me that they’ve been open for as long as they have.
My second complaint is the security design. They’ve had open issues about unauthenticated endpoints for three or four years now. And whenever the issue gets so old that it starts to look bad, they refactor the issue into a newer issue abd bury it in the sand.
You mean that one issue that is still open and linked in the “security and quality” tab on github?
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’m not using Plex, but I feel like I can answer my complaints about using jellyfin.
My biggest complaint is the lack of clients. It is such a pain in the butt to install jellyFin on all of my products.
My second complaint is the security design. They’ve had open issues about unauthenticated endpoints for three or four years now. And whenever the issue gets so old that it starts to look bad, they refactor the issue into a newer issue abd bury it in the sand.
For a while this was done under the guise of maintaining legacy client support, but just recently it looks like they’re starting to focus on more security, and I’ve noticed some of those security holes are being closed finally, but it’s a major concern for me that they’ve been open for as long as they have.
You mean that one issue that is still open and linked in the “security and quality” tab on github?
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?