I'm guessing that openssl was incorporated into OpenBSD base without
prior sufficient audit by the OBSD devs because it was presumed to have
better auditing / quality control upstream given its security critical
nature and function. (A number of devs have commented in the past about
the [lack of] code style, but I get the impression no-one expected the
degree of *sloppiness* now being uncovered.) So here's a question, are
there any other chunks of code that have been imported en-mass from an
upstream source that could/should use an audit? especially, something
that some of us non-developers might be able to assist with?
On 18 Apr 2014 at 19:06, Bob Beck wrote:
>
> On Fri, Apr 18, 2014 at 05:19:15PM -0700, Claus Assmann wrote:
> > Seems it is ok to use strlcat/strlcpy that way in some cases:
> > $ cat src/usr.sbin/smtpd/*.c | egrep -c ' strlc(at|py)\('
> > 249
>
> If your only goal is ensuring you don't have a non-nul terminated
> string, sure, that's great. and the way we like to indicate
> that you thought about that in code is to explicitly put (void)
> in front of it.
>
> so i.e.
>
> (void) strlcat(foo, bar, size)
>
> should mean you dont care if the value is truncated. and that's
> perfectly ok, because lots of times you dont.
>
> The problem is "what if bad things happen if the string is truncated"?
>
> I started looking just a short time ago, and will probably call it a
> night, why? well. my wife is asking me to put the computer down, and
> frankly, I need to rewrite the *second* function I got to. For your
> viewing pleaseure, please check out line 1124 of apps/ca.c There you
> see two strlcpys.. no problem right, but wait, we're building a path
> we're adding stuff on the end, if that / doesn't get there there are
> problems. oh look, then there's pointer arithmatic and some pretty
> crufty goo.
>
> This sort of tells me they never heard of asprintf.
>
> The point is in the *second usage* I go to look at it, I can't just
> look at that code and say "oh it's fine".
>
> Of necessity, some crypto code will be a bit scary to look at.
> anything that has to do regular jobs, like building a pathname, in a
> security library, should be a thing of beauty, not something that
> makes you want to throw up in your mouth. (and don't say it's just
> an app. I've seen what people do with this "app" and what
> they feed it data from..)
>
> sure, s/strlcpy/strncpy/ is 'better' - but this library is
> security code, and it should be clean, and modern. that's the goal
> here. not halfassed fixes with find and sed. If this is our fork,
> it will not be halfassed.
>
> -Bob
>
>
>
