dhclient in 6.0

Wed Mar 1 20:56:49 UTC 2006

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  
> that handles layer-2 ARP traffic per the recommendations in the link  
> above.  But I don't own the software in question, it was for a  
> client, so I'll have to see whether I can get permission before I can  
> redistribute anything....

Excellent!  Mail it to dhcp-suggest at 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  
> >reasonably
> >have been a part of this thread.  We should probably move the rest of
> >this off-list, if at all.
> 
> 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  
> 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  
> 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 at 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,  
> 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  
> 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
> 
> By my count, two-thirds of the bugs listed here (more than ten) were  
> 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

-- 
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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20060301/0b69fcd9/attachment.bin