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

help-circle
  • ShortN0te@lemmy.mltoSelfhosted@lemmy.worldJellyfin 10.11 RC1 Released
    link
    fedilink
    English
    arrow-up
    2
    arrow-down
    1
    ·
    2 days ago

    … and may also break compatibility with previous 10.Y releases if required for later cleanup work.

    If you read through the whole paragraph, it is clear that they mean the compatibility of previous jellyfin versions.

    Also, again:

    Note however that the 10.Y.Z release chain represents the “cleanup” of the codebase, so it should be accepted that 10.Y.Z breaks all compatibility,

    That means that the code is not cleaned up with that release.

    If you would release 11 before the code is considered cleaned up, you would basically break your own defined versioning convention. That is best decided by the active maintainers.


  • ShortN0te@lemmy.mltoSelfhosted@lemmy.worldJellyfin 10.11 RC1 Released
    link
    fedilink
    English
    arrow-up
    6
    arrow-down
    1
    ·
    3 days ago

    Consider the 10.y.z simply to be 0.y.z and everything works out.

    Jellyfin inherited a lot of shitty code and architecture from emby. They simply cannot guarantee anything across patches until it is sorted out.

    imho much better then releasing major version after major version because the break stuff regularly.













  • The scenario OC stated is that if the attacker has access to the user on the server then the attacker would still need the sudo password in order to get root privileges, contrary to direct root login where the attack has direct access to root privileges.

    So, now i am looking into this scenario where the attack is on the server with the user privileges: the attacker now modifies for example the bashrc to alias sudo to extract the password once the user runs sudo.

    So the sudo password does not have any meaningful protection, other then maybe adding a time variable which is when the user accesses the server and runs sudo







  • Do you want to prevent brute forcing or do you want to prevent the attack getting in?

    If you want to prevent brute forcing then software like fail2ban helps a little, but this is only a IP based block, so with IPv6 this is not really helpfull against a real attack, since rotating IP addresses is trivial. But still can slow down the attacker. Also limiting the amount of sessions and auth tries does significantly slow down the attacker.

    If you just want to not worry about it set strong passwords, and when it is a multi user system where other ppl might access it, configure Public Key Auth so you can be sure the other users have strong passwords (or keys in this case) to authenticate.

    With strong passwords or keys it is basically impossible to brute force your way in with ssh.