ShortN0te comments on People who are staying on Plex, have you tried Jellyfin? What about it do you not prefer? (real question)

[–] ShortN0te@lemmy.ml 1 point 4 months ago (8 children)

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.

permalink

fedilink

source

parent

hideshow 8 child comments

[–] BakedCatboy@lemmy.ml 1 point 4 months ago* (last edited 4 months ago) (7 children)

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?

permalink

fedilink

source

parent

hideshow 7 child comments

[–] ShortN0te@lemmy.ml 1 point 4 months ago* (6 children)

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"

permalink

fedilink

source

parent

hideshow 6 child comments

[–] BakedCatboy@lemmy.ml 1 point 4 months ago* (5 children)

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.

permalink

fedilink

source

parent

hideshow 5 child comments

[–] ShortN0te@lemmy.ml 1 point 4 months ago (4 children)

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.

permalink

fedilink

source

parent

hideshow 4 child comments

[–] BakedCatboy@lemmy.ml 1 point 4 months ago (3 children)

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?

permalink

fedilink

source

parent

hideshow 3 child comments

[–] ShortN0te@lemmy.ml 1 point 4 months ago (2 children)

I am saying all this because it's more blown up than it is. I have said in basically every single post that it needs to be fixed right? So pls do not suggest that I do not want it to get better.

But, this link to the collection of vulnerabilities gets posted on every argument without any explanation and or classification. Which is also not ok.

permalink

fedilink

source

parent

hideshow 2 child comments

[–] BakedCatboy@lemmy.ml 1 point 4 months ago* (last edited 4 months ago) (1 child)

For starters, it being brought up wouldn't be an issue if there was some timeline to fix it and the response wasn't just "it's too hard and would break clients", and secondly, I think it's not congruent with wanting to improve jellyfin if your reflex is immediately to say that nothing is truly secure. Could you imagine if next cloud had a similar issue and put it off for more than 5(?) years?? Is that really not enough time to get the clients and apps in order? They should just put the issue to rest so we can move on with making jellyfin better. I don't think anyone wants it to remain an issue for another 5 years, and I think calling that blown out of proportion is kinda ridiculous.

Like if 5 years ago they said you have 5 years to update your app, we could have had this issue checked off and nobody would be able to complain about it or use it as an excuse not to switch, so the next best time to set a deadline would be now. They should just as soon as possible say you have a couple years to update your apps, at least schedule a date years in the future to rip off the bandaid instead of kicking it further down the road.

permalink

fedilink

source

parent

hideshow 1 child comment

[–] ShortN0te@lemmy.ml 1 point 4 months ago

I think it's not congruent with wanting to improve jellyfin if your reflex is immediately to say that nothing is truly secure.

At no point in life I said that.

Jellyfin has proven with the latest RCEs that they can handle relevant critical security vulnabilities.

As always, jellyfin does not have that much relevant contributers, and a lot of work has been done in recent time. It is very easy to lean back and say what they should or should not have been doing.

Breaking Clients would make the project not usable for many ppl or at least decrease the usability.

As i have already said, getting uodatea on those closed eco systems can be a nightmare.

permalink

fedilink

source

parent