Announcement

Collapse
No announcement yet.

Another X.Org Security Bug Found, Dates Back To 1991

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

  • #11
    Originally posted by mark45 View Post
    Both, Linus's and Microsoft's conclusions are logically flawed.
    Open Source has more eyeballs, but each project is different and the code is different and the project members are different. Case in point - I wanna kill a few Qt devs because they're so nitpicky about the code I wanted to contribute.
    Whether the code is open or closed source doesn't make it "better" in any way, not even security-wise, there's always half-truths that you can pick to support either claim. It's just like those idiots who say "(all) women are bla-bla" or those idiot women who say "(all) men are bla-bla", and in each case pick only the facts that support their views. Democrats vs republicans, etc, typical logical crap.
    I agree.
    It is commonly though that being open source makes it inherently secure (or, at least, MORE secure). I don't think this is necessarily the case; complexity of software development invalids this assumption. Also, I think that, although the code is there for anyone to review, in practice only a handful are people actually do it, and even fewer people have the authority or experience to actually find a bug or some potential flaw.

    Comment


    • #12
      Originally posted by chuckula View Post
      There weren't enough eyeballs because most people who dare to look at the abomination of the X source code tend to go blind (and clinically insane) very quickly. Note that it was an automated tool that found the bug
      Not if they wear those cool shades like you just did

      Comment


      • #13
        Originally posted by phoronix View Post
        Phoronix: Another X.Org Security Bug Found, Dates Back To 1991

        Another X.Org Security Advisory had to be publicly issued today to make known a buffer overflow in an X.Org library that's been present in every X11 release from X11R5 and the code was completed way back in 1991...

        http://www.phoronix.com/vr.php?view=MTU2Mjg
        Something nice to watch
        Enjoy the videos and music you love, upload original content, and share it all with friends, family, and the world on YouTube.
        RBEU #1000000000 - Registered Bad English User

        Comment


        • #14
          Originally posted by mark45 View Post
          Both, Linus's and Microsoft's conclusions are logically flawed.
          Yes/No/Maybe. In any case, the cited 'law' is the one made up by ESR.

          Comment


          • #15
            Whoever this guy is that has found hundreds of bugs needs to be hired fulltime to patch all of these bugs. If he has these bugs then the NSA certainly does.

            Comment


            • #16
              Someone need to set up an automated infrastructure to run static analysis tools (such as cppcheck, pylint, phpcs, etc) on the whole Debian/Fedora source package tree.

              Comment


              • #17
                Fix or remove?

                Does this really have to be fixed?

                Cant that module or part just be removed?
                Is it really necessary these days?

                Does anything really make use of that functionality?

                Comment


                • #18
                  Originally posted by uid313 View Post
                  Someone need to set up an automated infrastructure to run static analysis tools (such as cppcheck, pylint, phpcs, etc) on the whole Debian/Fedora source package tree.
                  Actually I have that support in the commercial Phoronix Test Suite / Phoromatic enterprise stack but haven't yet found the time to make public version of it... If only I had more time in the day.
                  Michael Larabel
                  https://www.michaellarabel.com/

                  Comment


                  • #19
                    Originally posted by GreatEmerald View Post
                    Someone should track records for longest-running security bugs in X. 23 years sounds about right for the current record
                    Reverse OpenBSD claim, hah.

                    Comment


                    • #20
                      Originally posted by uid313 View Post
                      Does this really have to be fixed?

                      Cant that module or part just be removed?
                      Is it really necessary these days?

                      Does anything really make use of that functionality?
                      Ahh, see, this would be the logical course of action... but this is the X server we're talking about here. We've got to keep EVERYTHING and we've got to keep it UNTOUCHED in case something we do accidentally breaks the behavior in a super out-of-the-way corner case.

                      It made me sad when Wayland adopted a similar approach, since we've all seen how that worked out...

                      I've been thinking that a 2-release (major release, not point releases) lifespan of things you didn't actually want would be smarter.
                      E.g. you put in X feature in 2.0 but almost nobody used it (leading to nobody maintaining it) and it was starting to interfere with other things, you would be forced to wait until version 4.0 until you could rip it out, but you COULD rip it out.
                      Depending on the project, that 2.0 <--> 4.0 wait time could be super long or super short. On a display server, it could be a very long wait, but that just gives the complainers less to complain about.

                      Comment

                      Working...
                      X