• 0 Posts
  • 123 Comments
Joined 2 years ago
cake
Cake day: June 4th, 2023

help-circle

  • and you’re trusting this WAY too much.

    I don’t need to trust because I know how it works: https://github.com/jellyfin/jellyfin/blob/767ee2b5c41ddcceba869981b34d3f59d684bc00/Emby.Server.Implementations/Library/LibraryManager.cs#L538

    Tools like shodan will categorically identify EVERY jellyfin instance that scanners will run into.

    They can’t. Without the domain, the reverse proxy will return the default page.

    No. Read the whole thread.

    I did.

    If your path is similar to my path

    It does not need to be similar, it needs to be identical.

    • There are 2 popular Docker images, both store the media in different paths by default
    • You do not have to follow the default path
    • The server does not even have to run in Docker
    • The sub path is entirely defined by the user
    • You do not know the naming scheme for the content

    There are 1000s of variations you have to check for every single file name, with 0 feedback until you get a hit. After you have gone through all that trouble, you can now confirm that the file exists and do great things like retrieve the cover art or the subtitles. None of which is incriminating or useful.

    All it takes is for one angsty company to rainbow table variants of their movies name to screw you completely over.

    My threat model does not include “angsty company worried about copyright infringement on private Jellyfin servers”.

    Why bother scanning the entire internet for public Jellyfin instances when you can just subpoena Plex into telling you who has illegal content stored?


  • You are reading too much into the issue linked.

    In order to actually abuse any of the unsecured endpoints, you need to have knowledge of the domain, the media/user/stream IDs and media paths. You don’t get those unless you have a user on the Jellyfin instance and brute forcing them is not practical. If you trust the users you add to your Jellyfin instance, there is not much risk in exposing it to the internet.

    Those issues definitely need to be addressed at some point, but it doesn’t make Jellyfin exposed on the internet open to anyone.





  • Copying from an older comment of mine:

    IPv6 is pretty much identical to IPv4 in terms of functionality.

    The biggest difference is that there is no more need for NAT with IPv6 because of the sheer amount of IPv6 addresses available. Every device in an IPv6 network gets their own public IP.

    For example: I get 1 public IPv4 address from my ISP but 4,722,366,482,869,645,213,696 IPv6 addresses. That’s a number I can’t even pronounce and it’s just for me.

    There are a few advantages that this brings:

    • Any client in the network can get a fresh IP every day to reduce tracking
    • It is pretty much impossible to run a full network scan on this amount of IP addresses
    • Every device can expose their own service on their own IP (For example: You can run multiple web servers on the same port without a reverse proxy or multiple people can host their own game server on the same port)

    There are some more smaller changes that improve performance compared to IPv4, but it’s minimal.

    My unifi kit can convert us to IPv6 but I’m hesitant without knowing what devices it will break.

    You don’t usually “convert” to IPv6 but run in dual stack, with both IPv4 and IPv6 working simultaneously. Make sure your ISP supports IPv6 first, there is little use to only run IPv6 internally.





  • Assuming you get a OpenVPN config file for work or know the credentials: OpenVPN is integrated in most distros, no app needed. Just go to your network settings and add a new connection. Either add an OpenVPN connection if you want to configure it manually or if you have a config file, there is an option to import it.

    Doing it this way adds a simple toggle like turning on/off your wifi. Pretty neat.








  • I use the Flatpak and here’s how to get VA-API working:

    • Run the following command: ls -lah /dev/dri/render* and note down the number behind renderD
    • Create a project
    • Go to Project -> Render
    • Select VAAPI AMD H264 and click Save current preset as new custom preset
    • In the new preset, replace renderD129 with the result of the command in step 1, e.g. renderD128

    You should now be able to hardware encode with the custom preset. Since you have an 7900 XTX you can also use H265 and AV1 to encode. For that you can copy the preset again and replace h264_vaapi with av1_vaapi or hevc_vaapi. When using AV1, you also have to switch the audio codec to opus instead of aac.