Announcement

Collapse
No announcement yet.

Lennart Poettering - systemd + PulseAudio Creator - Departed Red Hat

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

  • Originally posted by kreijack View Post
    Let me to say in another way: if you don't need to checksum data, COW is not useful at all.
    COW enables cheap snapshots.

    Comment


    • Originally posted by wertigon View Post
      Does decoupling guarantee you will not find exploits? No. It merely lowers probability.
      It reduces the set of potential pair-wise interactions and improves testability. With all else being equal, those two properties of an architecture tend to result in better stability and security.

      Comment


      • Originally posted by ssokolow View Post
        In my experience, the rotated ones are, but not the current ones.
        Thanks to gzip & friends' support for compression of streams, you could use them to compress logs on-the-fly. Not sure if syslog supports this, but it's certainly possible.

        Not exactly relevant to the discussion at hand, but I just think it's a neat feature of these tools & compression formats.

        Comment


        • Originally posted by teldar View Post

          I can confirm he is currently at Microsoft.
          Is this supposed to be a secret? If true, isn't this a possible conflict of interest?

          Comment


          • Originally posted by cl333r View Post

            Off topic but I've been wondering: all open document files (.ods, .odf, ..) are zip files with a different extension so when you update say a text paragraph in your .odf file the LibreOffice editor has to do a ton of work when you press Ctrl+S: when opening the .odf it unzips all files into a temp location, changes the text in the proper file, builds a new zip file and replaces the existing zip file with the new one (with the corresponding extension instead).

            I was wondering if there could be a (smart?) binary format so that you just update that single text paragraph (or what have you) and that's it.
            As for size, maybe it could have optional compressed sections to save space. You know, a smart file format if you will. Maybe it already exists elsewhere for a long time I just don't know what it's called.
            Hoboy, that's just the start. Don't get me started on this. At work we have a spreadsheet that expands to like 750MiB of content.xml because of all of the redundancy and elaborate/poor design of the spreadsheet portion of ODF, and the particularly poor way that LibreOffice writes it, to say nothing of the mess across other parts of it. Takes 20 seconds to extract some already computed cells from it... but it's either that or a 750MiB fods (non-zip).

            Comment


            • Originally posted by evasb View Post
              Is this supposed to be a secret? If true, isn't this a possible conflict of interest?
              How could it be a secret? There will come circumstances where he is contributing to a free software project, the real ethical problem would be not disclosing that.

              Comment


              • Originally posted by microcode View Post

                How could it be a secret? There will come circumstances where he is contributing to a free software project, the real ethical problem would be not disclosing that.
                Anonymous sources that are disclosing that. I think it is pretty fishy.

                But good luck to him.

                Comment


                • Originally posted by coder View Post
                  Thanks to gzip & friends' support for compression of streams, you could use them to compress logs on-the-fly. Not sure if syslog supports this, but it's certainly possible.

                  Not exactly relevant to the discussion at hand, but I just think it's a neat feature of these tools & compression formats.
                  Good point. It'd probably give terrible compression ratios at the size log entries tend to be and given how duplication tends to occur more between entries than within them, but it's definitely a fascinating idea.

                  Comment


                  • Originally posted by wertigon View Post

                    You do realise what you are asking for is on the same level as proving Fermat's Last Theorem, yes?

                    Some things are known by deduction, but cannot be proven beyond a doubt. The exploit may happen in Journald, dbus, or any other part of systemd's two dozen programs and/or libraries and the millions of lines within.

                    Why do I know it will happen? Because humans fuck up. Because there isn't a single freakin' piece of complex software that has not been exploited at some point or another. Will the next systemd exploit happen in Journald specifically? Not necessarily, no.

                    Does decoupling guarantee you will not find exploits? No. It merely lowers probability. Just like a seat belt lowers probability of death in a car crash - it does not guarantee survival. Are seat belts a good idea? YES! And so is decoupling.
                    Making ridiculous claims, refusing to prove them and devolving into sophistry. As usual.
                    You said/implied that the current design "allows" something, therefore you get to prove it. End of story. Bye.

                    Comment


                    • Originally posted by intelfx View Post
                      You said/implied that the current design "allows" something
                      Nope, that's just you failing your reading interpretation skill check. And you seem to have rolled a 1, at that.

                      What I said was, that tight coupling increases the attack surface for (future) vulnerabilities. Low coupling decreases the attack surface at the cost of interface maintenance.

                      With lower attack surface, the chance of an eventual, hypothetical, yet to be invented exploit will, with all probability, not cause as much damage as an exploit towards an application that has higher attack surface.

                      Hypothetical example; journald gets compromised and piggybacks on the systemd communication to pwn the entire system. In a low coupled system, this would not be possible.

                      Now, are there mitigations against this in systemd? No idea. I sure hope so. But from what I have understood and of what I have read, any core systemd binary that gets pwned will lead to everything getting pwned because tight coupling. And it sure is harder to code 20-something different daemons securely, than one daemon. Especially since some of these speak with the network card.

                      That said, is systemd bad? No, not really. The design may be worse than XOrg, but other than that, no real complaints. It works great for what it needs to be, 99.9% of the time. With a better design that could be 99.999%.

                      Comment

                      Working...
                      X