7 ms·

A good and systematic approach to incorporate fuzzing findings would be as follows: 1) Identify a harmful input through fuzzing 2) Reduce the input to minimal

A good and systematic approach to incorporate fuzzing findings would be as follows: 1) Identify a harmful input through fuzzing 2) Reduce the input to minimal testcase 3) Contribute testcase and fix to existing code Note the absence of "rewrite the whole thing without tests" in this process. From-scratch rewrites that may or may not have fewer bugs than their predecessors are known as CADT. http://www.jwz.org/doc/cadt.html http://www.jwz.org/doc/cadt.html

userbinator 12y ago
CADT refers mostly to rewrites in which lots of new features and complexity are being added - the most likely sources of bugs - not to ones like this that go in the opposite direction.
- acqq 12y ago
  Let me quote from the source of the CADT term: http://www.jwz.org/doc/cadt.html http://www.jwz.org/doc/cadt.html "This is, I think, the most common way for my bug reports to open source software projects to ever become closed. I report bugs; they go unread for a year, sometimes two; and then (surprise!) that module is rewritten from scratch -- and the new maintainer can't be bothered to check whether his new version has actually solved any of the known problems that existed in the previous version." The OP rightly points that there are no known tests that demonstrate the known problems in the older implementations and also no proofs that the new implementation passes them.
  - raverbashing 12y ago
    Don't compare the Gnome development process with the OpenBSD development process. They are very different. Especially one being a core utility another a Desktop Environment. I agree with that critique of the Gnome development process, but the OpenBSD development process prides itself on security and that's a first commit, new changes are being added (as it can be seen by the log of that file - http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/usr.bin/file/file.c?sortby=date http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/usr.bin/file/fi... )

userbinator 12y ago

CADT refers mostly to rewrites in which lots of new features and complexity are being added - the most likely sources of bugs - not to ones like this that go in the opposite direction.

acqq 12y ago
Let me quote from the source of the CADT term: http://www.jwz.org/doc/cadt.html http://www.jwz.org/doc/cadt.html "This is, I think, the most common way for my bug reports to open source software projects to ever become closed. I report bugs; they go unread for a year, sometimes two; and then (surprise!) that module is rewritten from scratch -- and the new maintainer can't be bothered to check whether his new version has actually solved any of the known problems that existed in the previous version." The OP rightly points that there are no known tests that demonstrate the known problems in the older implementations and also no proofs that the new implementation passes them.
- raverbashing 12y ago
  Don't compare the Gnome development process with the OpenBSD development process. They are very different. Especially one being a core utility another a Desktop Environment. I agree with that critique of the Gnome development process, but the OpenBSD development process prides itself on security and that's a first commit, new changes are being added (as it can be seen by the log of that file - http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/usr.bin/file/file.c?sortby=date http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/usr.bin/file/fi... )