OpenBSD Journal

Patch 001 for OpenBSD 3.7

Contributed by grey on from the getting back to a slow start dept.

Thanks to Ryan Patterson for writing in with the following:

I noticed this during my morning romp...

"001: SECURITY FIX: June 7, 2005 All architectures
Fix a buffer overflow, memory leaks, and NULL pointer dereference in cvs(1) . None of these issues are known to be exploitable. CAN-2005-0753 ." A source code patch exists which remedies this problem.

Be sure to check as always.

(Comments are closed)

  1. By Anonymous Coward ( on

    hehe, a bug in gnu cvs...

    Soon we won't need to bother with that anymore... can't wait for opencvs :-)

    1. By almeida ( on

      Any idea how much more development OpenCVS needs before it replaces the existing CVS?

      1. By miguel ( on

        Not sure about the time, but by the moment, there is no code available :P

        1. By Matthias Kilian ( on

          It's in CVS (/usr/src/usr.bin/cvs), but I don't know how usable it is yet.

          1. By joris@ ( on

            the client side is pretty usable, although there might still
            be some bugs left, some commands are not supported yet.

            about the server side, i have a diff to get it going, hopefully
            that will go in soon. after that we need to finish the local
            command stuff, since the server relies on that.

            feel free to start testing opencvs, and give us feedback about
            what is missing or what bugs you encounter and how we can reproduce
            them, so we can fix them.

    2. By Anonymous Coward ( on

      How do you know that one doesn't have buffer overflows aswell. A language with automatic bounds checking please.

      1. By Bert ( blambert at thepresidency dot org on

        While you're at it, would you like a pony too?

      2. By m0rf ( on

        oh you mean a language written in C or written in a language written in C?

        1. By Anonymous Coward ( on

          Which is harder to validate -- a small chunk of C code that implements bounds checking for some other language X, or an infinite number of C programs which all may access arrays incorrectly? Your argument is equivalent to saying that since compilers have bugs we all might as well write in assembly. Progress is made by building more and more sophisticated tools, not by giving up because making something complex is hard.

          1. By Anonymous Coward ( on

            So, coding in C is hard... that's why we don't give up. :-)

      3. By Anonymous Coward ( on

        Yes, time to rewrite OpenBSD in Java! </sarcasm>

        1. By Anonymous Coward ( on

          I vote for Python!

  2. By gabriel ( on

    how those kind of "bugs" still manage to get trhu with today compilers and tools?


Copyright © - Daniel Hartmeier. All rights reserved. Articles and comments are copyright their respective authors, submission implies license to publish on this web site. Contents of the archive prior to as well as images and HTML templates were copied from the fabulous original with Jose's and Jim's kind permission. This journal runs as CGI with httpd(8) on OpenBSD, the source code is BSD licensed. undeadly \Un*dead"ly\, a. Not subject to death; immortal. [Obs.]