668
Jellyfin critical security update - This is not a joke (github.com)
submitted 7 months ago by to c/selfhosted@lemmy.world
183 comments fedilink hide all child comments
you are viewing a single comment's thread
view the rest of the comments
[–] 28 points 7 months ago (23 children)

Is it standard practice to release the security updates on GitHub?

I am a very amateur self hoster and wouldn't go on the github of projects on my own unless I wanted to read the "read me" for install instructions. I am realizing that I got aware I needed to update my Jellyfin container ASAP only thanks to this post. I would have never checked the GitHub.

  • permalink
  • fedilink
  • source
  • hideshow 23 child comments
    •
  • [–] 27 points 7 months ago

    Is it standard practice to release the security updates on GitHub?

    Yes.

    And then the maintainers of the package on the package repository you use will release the patch there. Completely standard operation.

    I recommend younto read up on package repositories on Linux and package maintainers etc.

  • permalink
  • fedilink
  • source
  • parent
  • [–] 2 points 7 months ago (1 child)

    I am realizing that I got aware

    I don't run the arr stack, but this is key. You really should do your due diligence before you update anything. Personally, I wait unless it's a security issue, and use all the early adopters as beta testers.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 1 child comment
    •
  • [–] 4 points 7 months ago (18 children)

    Not really.

    Depending on how you install things, the package maintainers usually deal with this, so your next apt update / pacman -Syuv or ... whatever Fedora does... would capture it.

    If you've installed this as a container... dunno.. whatever the container update process is (I don't use them)

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 18 child comments
    •
  • [–] 4 points 7 months ago (12 children)

    I indeed use a container. Wasn’t familiar with the update process for containers but now know how to do it.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 12 child comments
    •
  • [–] 5 points 7 months ago (1 child)

    There's a lot of good container management solutions out there that are worth investigating. They do things like monitor availability, resource management, as well as altering on versioning.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 1 child comment
    •
  • [–] 2 points 7 months ago (1 child)

    If you haven't already, I recommend Watchtower (nickfedor fork—the original is unmaintained) which automatically pulls updates to Docker containers and restarts them. Make sure to track latest, although for security updates, these should be backported to any supported versions so it's fine to track an older supported version too.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 1 child comment
    •
  • [+] -7 points 7 months ago (7 children)

    Lol it's already insecure then. Don't bother.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 7 child comments
    •
  • [–] 4 points 7 months ago* (5 children)

    Implying you have access to some major Docker 0-day exploit, or just talking out of your ass? Because a container is no more or less secure than the machine it runs on. At least if a container gets compromised, it only has access to the volumes you have specifically given it access to. It can’t just run rampant on your entire system, because you haven’t (or at least shouldn’t have) given it access to your entire system.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 5 child comments
    •
  • [–] -1 points 7 months ago (4 children)

    Docker is known insecure. It doesn't verify any layers it pulls cryptography. The devs are aware. The tickets remain open.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 4 child comments
    •
  • [–] 0 points 7 months ago (1 child)

    If that is indeed true it would only mean that the docker container is vulnerable to a supply chain attack. You are not any more vulnerable to a vulnerability in the codebase.

    If you’re using the ghcr image, to post malicious code there, the attack would have already had to compromise their github infra … which would likely result in the attacker being able to push malicious code to git or publish malicious releases. Their linux distro packages are self published via a ppa/install script, which I would assume just pull from their github releases, so a bad github release would immediately be pulled as an update by users just as fast as a container.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 1 child comment
    •
  • [–] 3 points 7 months ago (4 children)

    Unattended upgrades set to security only and never worry

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 4 child comments
    •
  • [–] 6 points 7 months ago (3 children)

    It's difficult to do security-only updates when the fix is contained within a package update.

    Even Microsoft's security updates are a mix with secuirity updates containing feature changes and vice versa.

    I usually do an update on 1 random device / VM and if that was ok (inc. watching for any .pacnew files) and then kick Ansible into action for the rest.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 3 child comments
    •
  • [–] 1 point 7 months ago (2 children)

    Why does unattended upgrades with security only setting not fix this?

    This is literally why Debian has distinct repos for security updates.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 2 child comments
    •