Re: update

[Jay Ashworth <jra () baylink com>]

----- Original Message -----
> From: "Keith Medcalf" <kmedcalf () dessus com>

> > From: NANOG [mailto:nanog-bounces () nanog org] On Behalf Of
> > Valdis.Kletnieks () vt edu

> > On Sat, 27 Sep 2014 21:10:28 -0400, Jay Ashworth said:
> >
> > > I haven't an example case, but it is theoretically possible.
> >
> > The sendmail setuid bug, where it failed to check the return code
> > because it was *never* possible for setuid from root to non-root to
> > fail...
> > ... until the Linux kernel grew new features.

> This is another case where a change was made.
>
> If the change had not been made (implement the new kernel) then the
> vulnerability would not have been introduced.
>
> The more examples people think they find, the more it proves my
> proposition. Vulnerabilities can only be introduced or removed through
> change. If there is no change, then the vulnerability profile is
> fixed.

[ quoting fixed because you were too lazy ]

We have established, Keith, that you place the boundary of the object
for which an end-deployer has administrative control in a different place
for the purpose of assigning blame than most other people seem to, yes.

The sendmail maintainers are *NOT RESPONSIBLE* for avoiding exploits that
cannot happen in any available or planned deployment environment, nor for
decisions made by the creators of those environments which *cause their
code to become exploitable ex-post-facto*.  That's the point which I see
being made here.  If that's orthogonal to your argument, so be it.

Could we drop this now?

Cheers,
-- jra

-- 
Jay R. Ashworth                  Baylink                       jra () baylink com
Designer                     The Things I Think                       RFC 2100
Ashworth & Associates       http://www.bcp38.info          2000 Land Rover DII
St Petersburg FL USA      BCP38: Ask For It By Name!           +1 727 647 1274