BIND and ISC DHCP Bug DB Opening for Guest Users

Update: to access the bug database, go to bugs.isc.org, click on the Guest login, and select “bug-list” for either DHCP or BIND 9.

We are excited to announce that, beginning July 7th, we will finally be enabling read-only Guest access to our BIND 9 and ISC DHCP bug database.

I know what you are thinking.

Every other open source project has had an open bug database for years. What took ISC so long?

First problem: Software support for Guests

First of all, our issue tracker software did not have a “Guest” access feature. We use Request Tracker from Best Practical. It is open source and otherwise meets our needs perfectly. We did spend a couple of years talking about migrating to JIRA, but that is a big project and we didn’t see the payback. Recently we noticed that the CPAN project was using RT and they had some kind of Guest access, so we asked Best Practical to port the module for Guest access to the software version we are using. They were great to work with, and recently delivered the patch. The feature enables us to create a new “public access” ticket queue which is viewable by anonymous guest users.

Next problem: Safe handling for possible vulnerabilities

We do not have any verified, undisclosed security vulnerabilities in our issue tracker.

However, it is possible that someone could mine old crash reports, find something that was never reproduced, or otherwise extrapolate from a bug report and find a vulnerability we missed. We put a LOT of effort into prompt and responsible disclosure of vulnerabilities and we certainly don’t want to inadvertently publish something that could be used against our users. This is why we feel we need to review any previously-reported, unresolved issues before publishing them.

The hardest problem: Expectation of privacy

We are also concerned about privacy. Some of our staff have told people posting on our public lists that they could email to our issue tracker if they needed a confidential exchange. Many people have sent in configurations, crash dumps, or explicit information about their network that they understood at the time would not be published. We have to respect past commitments we or former ISC employees may have made.

We don’t have time to read through our massive, dusty archives

It is much easier to have an open bug database if you start out that way. At this point, ISC has accumulated 17 years’ worth of embarrassing comments, ToDo list items, unverified and abandoned bug reports, and possible user confidential information in our issue tracker. For example, we have over 7,000 resolved BIND issues, over 800 rejected BIND issues, and several hundred open issues, most of which were created by ISC employees. This is simply much more than we can possibly review or curate at this point.

We don’t have the time to review all these existing issues for publication, but we have decided we aren’t letting that get in the way of opening the bug database.

New, externally submitted issues will be publicly viewable by default

The solution we have decided upon is to open up the issue tracker for new public reports, by default.

If you submit a bug to bind9-bugs@isc.org or dhcp-bugs@isc.org, or via our web bug report form after July 7th, we will triage it and put it into the open, viewable bugs queue - unless you specifically ask us not to, or it looks like it could be a security vulnerability. In the latter case, we will keep it in a non-public queue. Newly submitted suggestions sent to bind-suggest or dhcp-suggest@isc.org will go straight into a publicly-viewable queue without triage.

Note that when you submit an issue your email address and any attachments will also be visible. This is why we are announcing this change early - so that we have plenty of time to get the word out to submitters.

ISC internally-created issues

ISC employees create most of the issues in our issue tracker. Our development team opens issues for feature development (or any code commit), and to keep track of ideas for future work. Issues can also be opened automatically (e.g. by Coverity, which is scanning for possible regressions), or by our technical support team, reporting a problem on behalf of a support customer. We will obviously not be publishing any specific data provided by ISC support customers, but otherwise, we will try to be open about as many of our own issues as possible.

• In particular, we want to enable users to look up the issues resolved in a recent release, and read more detail on the bugs that were fixed.
• We also want users to be able to search, using their current and former email addresses, to retrieve old issues they submitted, to find out what happened to them.
• We are hopeful that people interested in contributing patches will consider attacking some of the open issues.
• Finally, we hope that some users will add their comments (via the email gateway) to issues they find in the open issue tracker.

Next Steps

We are still working on installing and configuring the new software, and re-testing it, to get it ready for July 7th. We are looking forward to sharing this information with our users and technical contributors.

We don’t want to discourage anyone from sending in bug reports, so if you have any concerns about your privacy, just mention in the body of your report, whether you submit it via email or the web, that you prefer that we keep your report confidential, and we will. Every bug report is read by one of our engineers and triaged, so we can simply put your issue into the non-public queue.

We have had to disable comments on our website and blogs, due to overwhelming abuse, but we invite your feedback on our bind-users and dhcp-users mailing lists, or directly to info@isc.org.