While I'm not strictly opposed to the idea of a vendors-only notification
list for BIND bugs from ISC, there are a number of things that have to be
kept in mind:

1) People can and do follow commit mailing lists. ISC/Nominum's commit
   mailing list may be private, but the commit lists for the *BSD projects
   are all public. It has been demonstrated on a number of occasions that
   people do actually read the commit lists, read the diffs, and that
   they aren't stupid. When security fixes are committed to the FreeBSD
   source tree and our advisory is delayed for whatever reason, e-mails
   start popping up on the FreeBSD security-officer mailing list saying,
   ``Are you going to release an advisory for this?'' ``This is a serious
   problem and if you don't release an advisory, we will'' ``Is this
   being covered up?''. We do try to coordinate the patching of bugs
   in our tree with the release of advisories, but a fundamental problem
   here has to do with the QA of the fix: CVS is how we serialize changes
   to the tree, as well as distribute the changes among developers. If we
   want wider testing in the developer community, it needs to be through
   CVS so that we have a "final" integration of the patch against a fixed
   version of the source tree. And as soon as it's committed, the world
   knows. Part of the goal of an open source and open development
   project is transparency -- most of the time, this is a benefit.

2) Getting fixes from the Vendor in advance of the release is very
   difficult. We delayed the release of our advisory because the
   "official" fix for the bug was BIND 8.2.3-RELEASE. It takes us several
   days to properly integrate a new vendor release into our tree on
   three code branches (5.0-CURRENT, 4.2-STABLE, 3.5-STABLE), develop
   and test updates against release versions, and do proper QA and
   testing. Releasing a broken fix helps no one: testing must occur
   first. Unlike what was claimed in an earlier e-mail, we had almost
   a month's advance notice of the vulnerability through CERT. We just
   didn't have the fix; we were asked to avoid disclosing the bug early,
   and it was clear to us that committing an advance fix prior to
   integrating 8.2.3-RELEASE would be about as plain to the concerned
   community as an advisory. We hoped that ISC/Nominum would release
   BIND 8.2.3-RELEASE in advance of notifying of the security problems
   in it, so that we would have time to integrate and test before
   the advisory. Instead 8.2.3-RELEASE went out the door on Jan 26,
   on a Friday late at night, and advisories begain popping up on
   Monday. Of course, the reality is that people diff releases to
   find security holes, as described in (1), so perhaps early access
   to the release doesn't work either. Trying to avoid releasing on
   a Friday would be a good thing, and has been discussed a number of
   times on bugtraq before.

3) The bind-members group sounds like it is really targetted at
   closed source systems: the reality of open source development is that
   it's done by large teams of people, that work is done by the first
   person who gets to it, resources for travel are relatively scarce, and
   that the people cooperating on open source software often don't have
   any binding contractual relationship. Requiring the signing of NDA's
   and the idea that in-person meetings be an important components of the
   organization will substantially hamper the participation of open
   source groups in the process. We discussed this to some extent
   internally in the FreeBSD Project, and came up with a list of no less
   than 8 people who would need to participate, based on the distributed
   nature of the security-officer list, maintainers of the BIND code
   in our tree, etc. And there isn't an "umbrella" organizationt that
   can sign the NDA and then delegate tasks internally. Also, the NDA
   may be quite incompatible with the nature of commit mailing lists,
   discussed above, which play a vital role in open source projects that
   use them.

4) As has been brought up, the NDA may present problems from other
   perspectives also: if it is known that a security vulnerability is
   being widely exploited, the "strong NDA" needs to take into account
   the desire for early release rather than delayed and coordinated
   release. If there is an NDA, it must come with a commitment that
   release of information and fixes can be done in a timely manner, not
   after a 30 day delay, during which time hundreds of thousands of
   machines are vulnerable. Having the root server operators in on
   the list is an interesting twist however, that may help: must
   vendor vulnerability mailing lists don't contain independent users
   of the products.

Vendors want, and need, advance notification of bugs so they can best
serve the users of their system. Doing this advance notification in a
structured manner is also necessary, to allow all interested vendors to
get notification, and to organize the advisory process to minimize risk to
the users of various systems. A failure to organize the advisory process
does a disservice to users of open source and closed source software, but
it's necessary to keep in mind the development models used in open source
software, and how they are not necessarily compatible with delayed
advisories, NDA's for developers, and timed release.

Robert N M Watson FreeBSD Core Team, TrustedBSD Project
robertfledge.watson.org NAI Labs, Safeport Network Services

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]