Re: Someone using COMPAT_SVR4(_32) ?

[John Nemeth <jnemeth%cue.bc.ca@localhost>]

On Aug 1,  8:03pm, Maxime Villard wrote:
} Subject: Re: Someone using COMPAT_SVR4(_32) ?
} Le 01/08/2017 à 19:30, Dave McGuire a écrit :
} >    Please forgive me for jumping in.
} > 
} >    History has shown that, in the general sense, the parts of an
} > open-source project that are fun and flashy get most of the attention
} > from developers.  Writing new whiz-bang features to show off in the
} > release notes is a lot more fun than chasing bugs and maintaining
} > existing code, so that's most of what happens.
} > 
} >    When you couple that with the "this is buggy, just rip it out"
} > mindset, what we'll be left with is just the parts that developers find
} > it fun to work on.
} > 
} >    Ripping out good features because they simply need to be fixed is an
} > awful idea.
} 
} No it's not. For your information, several vulnerabilities in compat_svr4
} were presented at DEFCON 25, and we now have wild kernel exploits out there,
} affecting NetBSD-6 and NetBSD-7. It's not just "buggy", it makes all of the
} system vulnerable - including your sparc64 machines.

     Uh, so what?  Bugs (including security bugs) are found in all
parts of the system on a regular basis.  Programming is hard.  "Any
program more complex then 'hello, world' is guaranteed to have
bugs."

} Again, if it "simply" needs to be fixed, why didn't you fix it? Seeing how
} things are turning out, this piece of code will not be maintained in the
} future, and therefore it will remain buggy for those who enable it.
} 
} As said earlier, Solaris is under active development, but our implementation
} has not kept pace with the changes.
} 
} If you would like to audit and maintain our compat_svr4 implementation, you
} are welcome. You can send patches to tech-kern@, they will be reviewed and
} certainly committed. But no one has ever audited it so far, and no one has
} shown any interest in doing that.

     This is a totally crap argument.  We do not regularly audit
code, which means that almost none of the tree has been formally
audited.  Most bugs are caught because they are hit, found by
Coverity, or caught in a regression test.  Ocassionally bugs are
caught by eyeballing the code (I've done this).

} Finally, removing this piece of code has little to do with shiny stuff. It

     Uh, who gave you permission to do this?  This is not the type
of thing that gets decided by a single random developer and I
haven't seen any statements by core.

} has to do with making the code base clearer, in such a way that several of
} our ports are easier to maintain, and as a result, more functional.

     More like your own personal vendetta.

}-- End of excerpt from Maxime Villard