Date: Wed, 1 Mar 2006 12:56:20 -0800 From: "David W. Hankins" <David_Hankins@isc.org> To: Charles Swiger <cswiger@mac.com> Cc: freebsd-stable@freebsd.org Subject: Re: dhclient in 6.0 Message-ID: <20060301205620.GD27931@isc.org> In-Reply-To: <7FBCD272-D73B-4EDC-9DC0-6845C186CE40@mac.com> References: <20060203130241.GJ44469@pegasus.dyndns.info> <c7aff4ef0602030524y3a2632d3w@mail.gmail.com> <60155.24.90.33.115.1138981486.squirrel@mail.el.net> <61418.24.90.33.115.1139004207.squirrel@mail.el.net> <20060204005501.GD7613@isc.org> <43E44BAD.50601@mac.com> <20060206225310.GA16149@isc.org> <43EB80D0.2090303@mac.com> <20060301001626.GM21419@isc.org> <7FBCD272-D73B-4EDC-9DC0-6845C186CE40@mac.com>
next in thread | previous in thread | raw e-mail | index | archive | help
--k1lZvvs/B4yU6o8G Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Mar 01, 2006 at 02:05:48PM -0500, Charles Swiger wrote: > Perhaps I'll be free to contribute some patches, as I've got code =20 > that handles layer-2 ARP traffic per the recommendations in the link =20 > above. But I don't own the software in question, it was for a =20 > client, so I'll have to see whether I can get permission before I can =20 > redistribute anything.... Excellent! Mail it to dhcp-suggest@isc.org, and we'll incorporate it as soon as we can review it. > >I think that exhausts your last DHCP related query that might =20 > >reasonably > >have been a part of this thread. We should probably move the rest of > >this off-list, if at all. >=20 > I didn't start the thread; Neither did I. I don't want to hijack it or this list for your or my own ends either. > and you asked for feedback about the usage =20 > of ISC DHCP under FreeBSD and for suggestions on what you could improve: That's not what I meant. Between the two of us, we've wandered off the purpose this thread presented. We're no longer talking about dhclient for FreeBSD and things that might be nice for that, we're talking entirely about open source security philosphy. It's just not topical. > If you didn't actually want to be answered, then I apologize for =20 > indulging your rhetorical questions. "We want secure software" is absolutely an adequate response. The point I'm trying to make is that we believe we already produce that; through application of the policy I've described in the narrow cases you presented. And there's very little I can do about the code that predates me on this project, except to improve it where I can. At this point, you are absolutely arguing that policy, and that's not topical. If you really want to argue it (and despite your claims to the contrary, it seems you do), I'm more than happy to move this off-list or to dhcp-server@isc.org if you want it to remain a public discourse, or to any other list freebsd or otherwise that you think is topical. But I'm pretty sure freebsd-stable doesn't care. > I'm not really interested in arguing with either you or ISC's policy, =20 > frankly. You appear, from the outside, to participate in activities you have no interest in. I must imagine this makes life very dull. > and you've convinced me that I'd be wasting =20 > my time discussing secure coding practices any further with you. Well, that depends on what you mean. If you want further insight on the policies I implement as an employee at ISC, I'm more than happy to discuss my best understanding of them with you, off-list or on any topical list. Or if you're going to IETF 65, I'd even be happy to discuss it with you in person there. If you want to actually acheive some kind of change in ISC's internal policies, I am powerless there. I suggest you contact a member of ISC's management team. I can even try to arrange an introduction if you require one. > If the policy results in useful, reliable, and secure code, > great...but even two out of three isn't bad. I wish I could count on > ISC's policy to also deliver secure software, but this policy hasn't > done so in the past [1], > [1]: http://www.isc.org/index.pl?/sw/bind/bind-security.php >=20 > By my count, two-thirds of the bugs listed here (more than ten) were =20 > buffer-overflow or bounds-checking failures; in particular: This is an excellent example of finding accurate, up to date information, and then coming to completely the wrong conclusion because you were missing out on how those events correlate, specifically, the timeline. It is from what was learned from bind 4 and 8 that current policy was formed, and after that bind9 was constructed; so measuring the success of the single policy I've mentioned, much less the success of the sum of all ISC's policies and people, against the bind4/bind8 track record is like comparing apples with orangutangs. Note the distinct lack of advisory in bind9. There have been three events. One was in openssl, which bind9 relies upon. There is very little we can do about that. Another was in libbind, which is actually pulled down from bind8...this is a relic of the past. The last was an overly zealous fencepost check...the server chose not to continue operating thinking it was internally inconsistent (and therefore likely to produce invalid output), when in fact it was the input from the network that was inconsistent. This third example is a combination of success and failure. We succeeded in enforcing correctness, and it was accomplished by accepting a vulnerability to this kind of DoS. Wether you or I or freebsd-stable like it or not, that is precisely what ISC's management have optimized our behaviour to acheive. Correctness at the expense of (dos-level) security and performance, security at the expense of even more performance, all else wherever we can fit it. I could accept your statement that you require the contrary and code to that requirement, but doing so would put my job in jeopardy: I would be violating ISC policy. And I like my job. This is the single greatest job I think I've ever had. So, it is not realistic to think that I am going to be able to do anything to get your security philosophy applied to ISC DHCP in any future release. It would also be far more truthful to state that ever since the combination of people and policies was constructed to produce the software known as bind9, which in small part I'm trying to explain to you these past few weeks, no significant event has ocurred that was a result of that work. One might think this supports the position that those policies are working effectively. In effect, the converse of what you're attempting to prove is the real truth. But it's better to be right because you're right, than to be right because no one has yet proven you wrong. What I mean is, we can and do review our procedures internally to further improve quality of code...we are not so proud as to think that a security vulnerability in bind9 (or any other product) is impossible. Now if only the last 12% of the market would select secure, useful, and reliable, over bind8 (or bind4 even): http://www.isc.org/ops/ds/reports/2006-01/dist-servsoft.php --=20 David W. Hankins "If you don't do it right the first time, Software Engineer you'll just have to do it again." Internet Systems Consortium, Inc. -- Jack T. Hankins --k1lZvvs/B4yU6o8G Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFEBgp0cXeLeWu2vmoRArSUAJ4+5ntzLdJeJXnDzgKHWnvUcxOxoACgjNsi HNTeSSCCPHtJYXkDkD9R9ME= =Ythm -----END PGP SIGNATURE----- --k1lZvvs/B4yU6o8G--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20060301205620.GD27931>