Re: Ability to withstand well known attacks

[ericb@digitaljunkyard.net]

 "fw" == Florian Weimer <fw@deneb.enyo.de> writes:

fw> ["no known issues" requirement]

>> I agree with the spirit of the requirement, but I just can't think
>> of any good way to express it that will be objectively testable

fw> Furthermore, it's a process thing.  Even if the vendor sells a device
fw> that has no known issues, the really interesting problem is how the
fw> fixes are distributed to affected customers.  "no known issues" is a
fw> moving target, and there has to be a process that reflects this.

That is beyond the scope of this requirement.

If my box is broken, and the vendor has a fix, then I can help myself.
I may not be smart enough to, I may not know how, I may not care, but
I CAN fix it if the urge strikes me.

If my box is broken, and the vendor does NOT supply a fix, then there
is absolutely nothing I can do to help myself.

Other parts of this document address how to configure devices so they
have no (few) issues.  Social problems involving patching are beyond
the scope of the document entirely.  At some points, the document
strives to make patching unneccessary, by preemtively fixing classes
of problems.  For those times where patching is still neccessary,
patching is still neccessary.

Yes, there is going to be latency as patches are developed.  There
will be even more latency when fixes are rolled into new versions of
code.  There will be even more latency as the fixes are backported
into old versions of code.  That comes back to Neil's "how long?",
which we can come to some agreement on.

This speaks to the resposiveness of a vendor to fix known problems
quickly, for current versions of code/devices.  There is some gray
area in "quickly", "known", and "current", but I can't imagine anyone
thinking this requirement is a bad idea.

ericb