Nope. I don't talk about myself like that.
I find I'm less of a prick about things if I'm not called things like "prick" and "shill".
Yet here we are. You've fulfilled the prophesy! Thanks for making the world a better place.
you can just make your case and see what happens first.
Oh... You mean like half dozen or so times that I've already brought this up over the past 2 years on lemmy, and a while before that on Reddit? It's only after I write a whole book on the matter that the upvotes kick in. And these discussions ALWAYS end up with much higher downvote ratios than most of the other stuff I comment on. Up to and including getting called names like "shill".
Example of the last time this was brought up that I participated in... https://slrpnk.net/comment/15703455 (which got mod removed it seems... it's still accessible to me on my server at https://lemmy.saik0.com/post/1622830) which was the "news" of a plex staff member leaving a comment for the plex app on the Google Play store...
Or this time... Where we were all complaining about the app redesign (which I also hate) https://lemmy.saik0.com/post/1517257... The root comment was lemm.ee though... which is gone. My comment starts at https://lemmy.saik0.com/comment/4476520.
I've discussed the matter ad nauseum.. and more often than not it's received pretty poorly. It's not a cop out or "bitch-ass pre complaint" when I have the history to point at.
Edit: Oh and here too... https://beehaw.org/post/19228632
You can use Jellyfin with wireguard and still have what Plex does.
Okay... Run wireguard on a roku TV or other many other common media devices. You can't...
Unless you want to run an open streaming service (which would probably be illegal in most countries anyway).
You can use Plex and JF both without actually hosting illegal content. You should still be worried about devs who refuse to fix a basic security issue that they actively block from being merged.
90% of Plex users probably don’t need what Plex does and would be happy with Jellyfin.
probably... and 99% of users likely have no idea how to secure things properly on their own. Which makes this whole premise even more dangerous for the "typical" person.
I didn’t say that. I agree with it though. They aren’t 1:1.
I was referencing the picture... which was the original comment I replied to. I recognized that your comment delineated that jellyfin should be offline. I appreciate that. I wish I saw more of that. This way we don't screw the new people to our media hoarding ranks. (I mean seriously... There's people like this out there... https://www.shodan.io/host/180.125.230.199 They're part of this community... somewhere.)
I like the interface more and feel its syncplay is less problematic.
It is... And I'm actually quite jealous that you have people using your server that you can watch movies together with... and are all using and capable of using a tunnel service without stupid amounts of support or other equipment limitations (good luck getting a vpn working on a Roku tv!). But if I want to syncplay with my family... plex is the only sane answer, regardless of it's functional flaws.
Edit: or even worse... This person...https://www.shodan.io/host/136.61.116.233 Where you can see the jellyfin service user that has a valid login on rdp... and their jf is accessible at jellyfin.nonooculusnas.com. It's even behind Nginx Proxy Manager! (which is recommended by the JF dev team) Yet still responds to probing for content...
Feels strange to me that we just accept
comments like these that imply that jellyfin is a direct replacement for Plex when you yourself say it's not. Especially an implication that you'd only "hack one" when the software itself has a massive gaping hole on ALL installs. Your only saving grace is if you deviate from "standard" install procedures.
I've already mentioned it several times. I want to dump Plex. I don't like the SSO that they solely control. I don't like many of the changes that they've made in the 12 years I've been using it. It's still the best product for watching my content.
Nobody is running Jellyfin strictly offline. At the bare minimum people leave it internet connectable to grab metadata and other resources, and more realistically in the context of a topic about Plex, Jellyfin would need to be internet accessible because that's why people are using Plex. The jellyfin devs have already made it clear they don't care about security issues. Why are you trusting the software when they ignore simple to fix issues that have merges waiting but they won't implement because "reasons". What other issues could be lurking leaving you open for liability? If someone can show you an issue from 5 years ago that is categorically a security issue and the devs refuse to fix it... you should also be questioning EVERYONE who advocates it's use to replace a service that's meant to be accessible in the way Plex is.
Edit: adding a little bit... forgot about it.
If you just changed your password and now you don't have access... Directly connect to the server http://
<serverip>
:32400/web and you'll get the setup prompt to connect it back to your account.If that doesn't work you can restart the server and try again (should catch up that it's unauth'd). Or run a tool like https://github.com/ChuckPa/UserCredentialReset to reset it so you can reauth it.
I just edited what I meant to originally send.... Now I'm replying so you get flagged and can look at it. Sorry that I fat fingered the enter button and jacked up the thread. My bad.
Stolen is a bit loaded in my opinion... XBMC was open source. All the parts that rely on that are available for free. Lots of websites out there sell shit... and run off of NGINX or Apache. taking open source things and building on them is common at this point.
I’m curious what youd think a kind of worst case scenario would be for any of the current jellyfin auth issues. Like what would someone with bad intentions be able to do?
Edit: Fuck, hit enter early... one moment. Edit2: here we go...
you have your setup... you configured it like the git repo said too and even used the container guide told you to (https://jellyfin.org/docs/general/installation/container/). You have now standardized the path... because the internal path that is recommended in the official compose will likely not change... (especially in the linuxserver version, https://hub.docker.com/r/linuxserver/jellyfin). Then you hear about *arr stack stuff and how people evangelize that on this platform too ( I'm one of them!). Standard naming convention gets applied there too...
So now bigbucksbunny.mov is stored on /data/movies/bigbucksbunny(2008)/bigbucksbunny.mov. You can pre-calc that md5 hash and probably nail people right now and get a result. Now be SONY or some other lawsuit happy studio. Grab a list of all your releases and precompile common paths and names (this would like be something that an LLM would be good at doing... fetching lists of paths that people post on reddit and other places)... generate the MD5 list. Maybe 1000 permutations of your top 10 movies... bonus points if there's no physical release (since you could claim that you ripped the content yourself... can't do that on streaming only content). Curl through the list of 10000 variants... if you get a hit on anything then you know they have your content... and it's publicly accessible (which could be argued in court for distribution... though I'm not a lawyer and don't know how reasonable that is.) You as the owner would then be on the hook... and lawsuits would commence promptly.
This is a potential "worse case" in my mind. Of course because they have evidence of access direct from your system, they can then subpoena access to the whole system... where your whole library becomes available for them to search further for more copyright violations and now your in real deep shit to explain to the courts.
Now... if you're in a country that doesn't care! Cool... just stop recommending Jellyfin to those that would get fucked by this. Are there ways to mitigate this highly? Absolutely... fail2ban, anubis, cloudflare bot detection shit, changing paths or adding GUID to your media library path... all can probably fix this... But none of that is in the jellyfin docs... and NOBODY else seems to mention it except for me when this discussion comes up... So how many people are actually doing it?
Don't expose Jellyfin and you don't have a competitor program that does what Plex does... stop recommending it as a replacement if it's not a replacement. And this is ignoring that it's recommended to expose to the internet on their own documents.
But you are forced to make a Plex account, if you want to use it.
You've missed the point. You can't be mad at plex for taking action and closing security gaps after becoming aware of them... then in the same breath recommend a service that can't even be on the internet because it's so poorly secured.
I think people think that I'm anti-jellyfin or something. I'd love to dump Plex... I WANT to dump it so bad (basically the day they did the arcade shit I've been highly turned off, what was that? 6 years ago?). But Plex is the best tool for what I need. Jellyfin could be there... But it's not. Everytime I see it recommended blindly without the massive caveats (especially in the context of a random Plex fuckup that is substantially less of a problem) I just feel compelled to attempt to remind people. I dunno. Deaf ears maybe... but blind trust just because it's open source isn't the answer either. And honestly it turns me off contributing to some of the projects that I do because if I was to speak out about problems in those... how many people would listen?
The most succinct response I've seen on the matter "The statements The Jellyfin Project makes about exposing Jellyfin directly to the Internet, without a reverse proxy, is less about Jellyfin being insecure and more about there being no effort made to make Jellyfin secure."
That would be a perfectly valid answer... But the Devs have posted several times that they're not interested in resolving it.
I'd accept a checkbox on install of Jellyfin for "Check this box for better security... some unsupported software might not like this. Go to Options/blah/blah to change this later if you need to change this later."
I'd probably shut the fuck up about this whole thing and dump Plex. But every single time Plex ends up in an article there's people singing praises about Jellyfin when there's completely open endpoints... It just baffles me. Downvotes be damned, I'll bring it up though when I see it since the devs won't bother telling people their software has a potentially big problem (especially if you use default configs, docker, and *arr stacks).
That’s not how the endpoint works. It is a randomized UUID.
It's not. It's an MD5 of the filepath. UUIDs are generic and random, not specifically tied to something.
https://github.com/search?q=repo%3Ajellyfin%2Fjellyfin+md5&type=code
If you do a basic search, you'll find that most api endpoint generated values are simply md5 of the filepath. And they just call this a GUID in the code... it's not. It's completely determinable. And the problem with this is expounded considerably if you use a default docker config (so folder path is known) and an *arr stack (so filenames get standardized). How many people modify these things significantly? Pre-hash a few permutations and just check away... Get someone like Sony (who've installed rootkits on people's computer before... so they don't give a shit), and now you could find yourself in court.
https://github.com/jellyfin/jellyfin/blob/3936fc9f253d15ae31afbdfe5fcf1684c441263c/Jellyfin.Api/Controllers/VideosController.cs#L315 is the api call itself. No auth.
Depending on your security posture
Is exactly the problem I have though with the evangelical preaching all about jellyfin here. I've brought this topic up probably about a half dozen times in the 2 years I've been on lemmy... and a while longer before on Reddit. DOZENS of people comment the same things you are... and get it completely wrong. And many more end up messaging me or responding that they had no idea this was an issue. Yet I continue to see people singing praises of Jellyfin! and how it must be so much more secure! When it completely isn't. So many people brush it off... then flip their shit about Plex doing something.
Especially since they’re gonna get blocked by http probing detection after a few tries.
If we're talking "mitigations". Plex is more secure by default... and if you want to get off their auth... you can access your network via VPN and set the VPN subnet as "local" so you don't have to do their auth. But at least plex doesn't just let unauthed people access whatever they can guess as a default out the box option. And certainly don't have any security issues sitting around for 5+ years waiting for a dev to do something about it.
Edit: forgot to finish a thought. Finished it.
Edit2:
This was my only comment in the thread. Kinda feels like your reply here is taking out your frustration with this entire thread on my reply.
Which immediately points to Jellyfin... as if it was "better" somehow. while downplaying the actual issue without actually reading what I'm complaining about
That unauthentic endpoint shit is so overblown.
Overblown if you have mitigations? Sure... but how many do? And why are we treating software that is taking actual actions to better security as "Worse" than something that can't clear a simple problem in 5+ years because devs don't want to "break compatibility".
Edit3: OH! forgot this as well... "well they'd need to know where to find servers before they can access them to check!" Yup.. hello shodan! https://www.shodan.io/search?query=jellyfin Would be trivial to make a script that does all of this and crawls shodan or other sources for domain/ip information. Hell you can probably just look up all LE certs issued that contain "jf" or "jellyfin" or other permutations of subdomains too. But shodan has a list of 11,788 when I check... that's not insignificant...
Good servers would serve data only to those authenticated to receive it! Which Jellyfin clearly isn't.
Complete access to your media without authentication isn't "don't give you any data".
Meanwhile you're all frothing at the mouth cause Plex leaked email addresses and encrypted passwords.
And you're correct. It's not a breach... because it wasn't protected to begin with.
Edit: You ninja edited your post... bad nettiquette.
put the endpoints behind your own authentication through your reverse proxy.
Breaks every app for jellyfin including tv apps. So no. that's not a valid answer.
Edit2: And I want to be clear about this... I don't simp for Plex I want off of the platform too... But Jellyfin in it's current state is a much worse security nightmare IMO. I can at least kill the plex relay binary and packet sniff it to know that it's not sharing data I don't want it to share. Jellyfin just lets everyone in that can guess a filepath (which you can "fix" by obfuscating it... but ask any security professional about that.) and somehow Jellyfin is the messiah? Devs ignoring a 5+ year old issue that already proof-of-concepted... is wild.
You don't even have to hack jellyfin though. Quite a few endpoints aren't behind authentication at all.
But that doesn't help your case so I'm sure you'll just downvote me.
Edit: For those who don't know. https://github.com/jellyfin/jellyfin/issues/5415
Several issues. Some require being logged in with any account (to get other user information on the server, including admin)... others are endpoints that let media access if you guess a guessable md5 hash(which is normalized in docker setups in general... and standardized by *arr setups. So highly guessable if you use these tools... which most of you are). The sort of thing that media companies will absolutely abuse eventually if they're not already doing it to collect proof that you're hosting their content illegally. But I just find it laughable that this is the answer... but ya'll are frothing at the mouth over plex leaking an email address... Oh no! not the email address you already get boatloads of spam at! However will you live!
Okay, next find the one where the kid doesn't get consent from the remote control...
So much fear mongering and incorrect statements... and I'm only 3 minutes in. I can't...
Nearly all encryption mechanism currently in use on the modern internet is quantum resistant. Breaking RSA-2048 would require millions of stable, error-corrected qubits. I believe the biggest systems right now are at 500 bits at most.
The NIST Post-Quantum Cryptography project has finalized new quantum-resistant algorithms like CRYSTALS-Kyber and Dilithium. These will replace RSA and ECC long before practical quantum attacks exist. Migration has already started.
Symmetric cryptography is mostly safe. Algorithms like AES, SHA-2, SHA-3, and similar remain secure against quantum attacks. Grover's algorithm can halve their effective key strength. Example: AES-256 becomes as secure as AES-128 against a quantum attacker. To crack on AES-128 hash with current efficiency you need ~88TW of power... Even if we make it 10 or 100x more efficient over time... It's too expensive. We don't have the resources to power anything big enough to crack aes-128... The biggest nuclear reactor (Taishan) only puts out a mere 1,660MWe...
It's not happening in our lifetimes. and probably not at all until we start harvesting stars.
Edit: Several typos.
Edit 2: For the AES-256 example that get's reduced to AES-128. It would take implementing efficiencies that reduce power usage by 1000x (there's a few methods that might get worked out in our lifetimes... lets just take them as functional right now). Then you'd need 55 of the biggest nuclear reactors we have on the planet... Then you wait a year for the computer to finish the compute. That decrypts one key.
Weaker keys might be a problem. Sure. But by the time we're there... it won't matter. For things like Singal, Matrix, or anything else that's actively developed... Someone might store the conversation on some massive datacenter out there... And might decrypt it 200 years from now. That's your "risk"... Long after everyone reading this message is dead.
Edit 3: Because I hadn't looked at it in a few months... I decided to check in on Let's Encrypt's (LE) "answer" to it. Since that's what most people here are probably interested in and using. First... remember that Let's Encrypt rotates keys every 90 days. So for your domain, there's 4 keys a year to crack at a minimum. Except that acme services like to register near the halfway point... So more realistically 8 keys a year to decrypt a years worth of data. But it turns out that browsers already have the PQC projects done... And many certificate registrars already support it as well. OpenSSL also supports it from 3.5.0+...
https://community.letsencrypt.org/t/roadmap-request-post-quantum-cryptography/231143/9
https://developers.cloudflare.com/ssl/post-quantum-cryptography/pqc-support/
Apparently LE is even moving to MUCH shorter certs... https://letsencrypt.org/2025/02/20/first-short-lived-cert-issued 6 days... So a new key every half-week (remember acme clients want to renew about halfway through the cycle)... or ~100 keys a year to break. Even TODAY, you're not going to need to worry about "weak" encryption for decades. It will take time for the quantum resources to come available... it will take time to go through the backlog of keys that they are interested in decrypting EVEN IF they're storing 100% of data somewhere. You WILL be long dead before they can even have the opportunity to care about you and your data... The "200 years from now" above reference... is assuming that humans can literally harvest suns for power and break really really big problems in the quantum field. It's really going to be on the order of millennia if not longer before your message to your mom from last year gets decrypted. LE doesn't have PQC on the roadmap quite yet... Probably because they understand there's still some time before it even matters and they want to wait a bit until the cryptography around the new mechanisms is more hashed out.
Edit4: At this point I feel that this post needs a TL;DR...
If you're scared.... rotate keys regularly, the more you rotate, the more keys will have to be broken to get the whole picture... Acme services (Let's Encrypt) already do this. You'll be fine with current day technology long after (probably millennia) your dead. No secret you're hiding will matter 1000 years from now.
Edit5: Fuck... I need to stop thinking about this... but I just want to point out one more thing... It's actually likely that in the next 100 (let alone 1000s of years) that a few bits will rot in your data on their cluster that they're storing. So even IF they manage to store it... and manage to get a cluster big enough that either takes so little power that they can finally power it... or get a power source that can rival literal suns. A few bits flipped here and there will happen... Your messages and data will start to scramble over time just by the very nature of... well... nature... Every sunflare. Every gravitational anomaly. Every transmission from space or gamma particle... has a chance to OOPS a 0 into a 1 or vice versa. Think of every case you've heard of Amazon or Facebook accidentally breaking BGP for their whole service and they're down for hours... Over the course of 100 years... your data will likely just die, or get lost, be forgotten, get broken, etc... The longer it takes for them to figure this out (and science is NOT on their side on this matter) the less likely they even have a chance to recover anything, let alone decrypt it in a timely matter to resolve anything in our lifetimes.
These timers have no concept of understanding if the air is too humid.
They want a cooldown period so the unit isn't cycling constantly.
eg. turning on and off 30 times in an hour because the sensor triggers the moment it see's 46% when it's set to 45.
They want it so that it triggers on pull humidity down to 45%, wait an hour no matter what then trigger the next time it sees 46% or greater, which could be immediately... or in 5 more hours.
A pure timer wouldn't get the same effect at all.
Best answer I can think of off hand would be Home Assistant related. Get a humidity sensor and a z-wave switch/outlet. Use a dumb dehumifier that turns on as long as it has power...
On humidity sensor change check if above 45%. If it is, turn on power. wait until below 45% again... turn power off then wait 60 minutes. Make sure automation is set to not run concurrently, that way the currently running automation script must complete it's 60 minutes cooldown before it can run again
I feel at this point that you just wanted to write "prick" as many times as you could in one sentence... Have at it.