Changes to BIND 9 development helped catch bugs
Yesterday I blogged about how ISC has been changing our internal development practices for BIND 9. Today, with the release of several security patches, I wanted to talk a bit on how they have helped us already.
In many projects, and previously in BIND 9, tests were written after the code was working. This left writing automated tests as an afterthought at best, and meant our tests were not as robust. One common problem was that the test didn’t actually test what we thought it did.
Now BIND 9 developers at ISC write a test first, which highlights the defect. Once a patch is found, the test should begin to pass. This confirms that we have properly repaired the defect and we have a test to prove it.
Filling in tests
“Untested code is buggy code.” This is a reality in any project regardless of size. We’ve started doing something about our untested code.
One of the security flaws found today was a product of this back-fill of test coverage. We started with the most important types of features (ACLs in this case) and started writing tests based on documented behavior. The output of this is either a bug fix or a documentation fix, when an error is found.
As we continue to modernize and improve our development practices within ISC, expect us to find more bugs. We prefer to find them before our customers do, and not only when they are security related. We also hope to catch more before they get out the door.
- BIND 10
- Other Software Projects
- security advisories
- software forums
- ABOUT ISC