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)\('
> 249If 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
