Announcement

Collapse
No announcement yet.

Systemd 251-rc1 Released With Experimental systemd-sysupdate Tool

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • #31
    Originally posted by mSparks View Post

    And if you had bothered paying any attention to any of the current "automatic discovery and install" tools, from upnp to windows update and solarwinds you would know they are a massive attack surface for pwnage.
    ...

    Why all that risk? dont know, reasons I guess.
    So you don't understand the differences between windows update, solarwinds and systemd's update which are wildly different and you also don't understand the use cases and how it is being used yet you claimed that you can somehow install using a malicious source and you were obviously wrong about that claim. Feel free to prove otherwise.

    Comment


    • #32
      Originally posted by RahulSundaram View Post

      Feel free to prove otherwise.
      Thanks for the offer but I think I'll just stick with a version of systemd that doesn't have this "feature" then laugh at you when I'm inevitably proved right.

      Last time I made that decision for similar was to stick with log4j 1.1, rather than open the door to a sketchy looking network API. It took a few years, but that really was minimum effort for maximum comedy.
      Last edited by mSparks; 02 April 2022, 08:16 AM.

      Comment


      • #33
        Originally posted by mSparks View Post

        Thanks for the offer but I think I'll just stick with a version of systemd that doesn't have this "feature"
        So you failed to prove the issue or even coherently explain the threat model as expected and your plan is to stick with an older unmaintained version which will have known security vulnerabilities in order to avoid an entirely optional feature in a new version?

        Comment


        • #34
          We have some of the stupidest arguments on here.

          It took a while for people to start using systemd-resolvd even after it had been released. AFAIK there are no major distros that use homed yet. WIth sysupdate, it is a component that can be used, but doesnt have to be.

          Now getting on to the bit I wanted to talk about: SIlverblue. it uses OStree. I love using it. However I cant help but feel it is limping along these days. It is stable and will probably continue being developed, but it is rare to see development that takes place targetting specificly silverblue. Kind of like they think it is already "complete".

          Comment


          • #35
            Originally posted by RahulSundaram View Post

            So you failed to prove the issue or even coherently explain the threat model as expected and your plan is to stick with an older unmaintained version which will have known security vulnerabilities in order to avoid an entirely optional feature in a new version?
            What part of "this will add RCE vulnerabilities to systemd" did you find unclear or incoherent?
            Yes, I will take "definitely doesn't have RCE vulnerabilities" over "has RCE vulnerabilities by design" every day of the week. You failed to prove any need or desire for this "feature", let alone a compelling enough need to open init to a backdoor autoinstaller.

            Comment


            • #36
              Originally posted by mSparks View Post

              What part of "this will add RCE vulnerabilities to systemd" did you find unclear or incoherent? .
              The claim is entirely incoherent.

              Originally posted by mSparks View Post

              Yes, I will take "definitely doesn't have RCE vulnerabilities" over "has RCE vulnerabilities by design" every day of the week
              You haven't show any design flaw at all.

              Originally posted by mSparks View Post

              You failed to prove any need or desire for this "feature", let alone a compelling enough need to open init to a backdoor autoinstaller.
              You haven't yet understood that an optional tool that is part of systemd doesn't make it part of init. Have you read the man page or the link I provided yet?



              Comment


              • #37
                Originally posted by You- View Post
                Now getting on to the bit I wanted to talk about: SIlverblue. it uses OStree. I love using it. However I cant help but feel it is limping along these days. It is stable and will probably continue being developed, but it is rare to see development that takes place targetting specificly silverblue. Kind of like they think it is already "complete".
                There are multiple improvements that continue to be made. A couple of recent examples:

                https://fedoraproject.org/wiki/Chang...les_rpm-ostree

                https://fedoraproject.org/wiki/Chang...ativeContainer

                Comment


                • #38
                  Originally posted by RahulSundaram View Post

                  The claim is entirely incoherent.



                  You haven't show any design flaw at all.



                  You haven't yet understood that an optional tool that is part of systemd doesn't make it part of init. Have you read the man page or the link I provided yet?


                  Either it discovers and installs remote code automaticallly - bypassing the normal update procedure or it doesnt.
                  There is no "optional" half way measure.

                  Are you saying it doesnt discover and install remote code automaticallly?

                  You and the op completely fail to justify WHY systemd or its users need this "feature", and last time I checked Remote Code Execution was "considered harmful". Absolute JOKE you think its up to me to prove an RCE feature is not harmful.

                  Comment


                  • #39
                    Originally posted by mSparks View Post
                    Either it discovers and installs remote code automaticallly - bypassing the normal update procedure or it doesnt.
                    There is no "optional" half way measure.

                    Are you saying it doesnt discover and install remote code automaticallly?


                    You and the op completely fail to justify WHY systemd or its users need this "feature", and last time I checked Remote Code Execution was "considered harmful". Absolute JOKE you think its up to me to prove an RCE feature is not harmful.
                    This conclusively demonstrates that you didn't read the docs at all. Hint: it is user configurable, not the default, entirely optional and when it is configured in a specific way used by specialized image based update systems only, it uses the same underlying security mechanisms used by Android, Chrome OS and millions of other devices. If you don't understand something, either read up on first or atleast ask how the feature works before posting silly claims next time.

                    Comment


                    • #40
                      Originally posted by RahulSundaram View Post

                      This conclusively demonstrates that you didn't read the docs at all. Hint: it is user configurable, not the default, entirely optional and when it is configured in a specific way used by specialized image based update systems only, it uses the same underlying security mechanisms used by Android, Chrome OS and millions of other devices. If you don't understand something, either read up on first or atleast ask how the feature works before posting silly claims next time.
                      Good grief no. Making a bad idea optional doesn't make it a good idea.

                      It just makes it an optional bad idea.

                      Although that kind of absolutely insane rationale is surely the motivation behind sites like:
                      https://nosystemd.org/
                      Last edited by mSparks; 03 April 2022, 04:52 PM.

                      Comment

                      Working...
                      X