Re: Theo chiming in on strlcpy

[Marc Espie <espie%nerim.net@localhost>]

On Sun, Dec 22, 2013 at 10:46:42AM +0700, Robert Elz wrote:
>   | I know I won't change your mind. I don't care to.
> 
> Good, but you brought this issue to this list.  You didn't need to.

I think it is interesting statistics.

>   | Nope, I'm more concerned about the undecided people.
> 
> So am I - and I hope they'll decide that software needs to be correct.
> To be correct, it needs to be correctly written, using whatever tools
> are chosen appropriately, and with good safety principles in mind.
> If that's done, it doesn't matter if the tools chosen could be dangerous
> in less experienced hands - and it is simply nonsense to claim that
> anything built using a dangerous tool is necessarily inferior to a similar
> product built using safer tools - the issue is all about how they're
> used.

My claim is somewhat more complex. Most code is boring. It just has to be
written in the safest, simplest way. That's why I will always prefer snprintf
to sprintf and strlcpy, because it's a simple, easy to read, easy to reproduce
pattern.  Sturgeon's law applies: in any piece of code, at least 90% doesn't 
really matter, when it comes down to performance, and memory usage. That part 
of the code, ideally, should be written in the most mundane way imaginable, so
that people reading it should be able to say "that's obvious".  So using the
same obvious patterns of code again and again and again helps.

Yes, there is a place for imagination and creativity. It's in the last 10%
of the code.  And those are not just numbers I pulled out of thin air, that's
what you actually see as soon as you start using a profiler on any code.

Yes, there are people who write correct code,  there are also ways too many
people who write incorrect code.  Often, you will not have time to audit it
all, you will take a piece of software, read a few hundred lines, and decide,
based on that, whether you should trust it.

Being sloppy in a part of it, even if it's in configuration files, like for
nmh, is no excuse.   It makes it very difficult for people to trust you,
the reasoning being, if the author didn't care enough to make it things correct
there, why should I trust him to care elsewhere, when it really matters.

There's also the fact that, other the last 20 years or so, I've seen countless
advisories that amount to a very unlikely chain of events exploiting weak
links in the most bizarre way imaginable (remember the buffer overflows in
Internet Explorer URLs ? you know, the ones that "can't happen", since it's
impossible to exploit UTF16 overflows to write code).

So, with limited time to write code, I err on the side of caution.  I don't
even feel constrained by it.  There are so many many ways to express
yourself, even if you try to abide by strict coding guidelines.

Let me have some parting words: I didn't bring this information to this list
to start a flame war.  I thought that this data is interesting, and I think
we *all* have a vested interest in helping create better software. I still
think the situation is moving wayys too slowly, and that we have an incredible
pile of half-functional, broken ticking bomb software in our respective ports
tree.  I think the industry is moving incredibly slowly in that respect, and
that people today still haven't learnt.

Just to be perfectly clear, it's not dogma. I'm not the Voice of Theo or
anything (heck, hell knows I've had some violent disagreements with him in
the past, I'm perfectly able to form my own independent opinion and stand
my ground).  So, please let's put aside the "us vs them" issue. Yeah, I'm
not NetBSD, so what ?

Personal information, I've spent the last ten years in contact with a 
lot of students.  Showing them the basics of C and Unix, then explaining 
to them how to write robust code... with among other things, the audit 
of real projects (in my opinion, this should be mandatory, when you have to
read other people's code, you realize you can make things a lot more obvious
to them by being less clever).  Invariably, they found actual issues.  
Some of them really scary and exploitable.

It's the end of 2013, and a vast majority of developers still write
buffer overflows when they use C or C++, and are just as sloppy when they
use other languages (the next obvious issue is sql injection, most junior
programmers don't even know what the term means; the next unobvious issue
is race conditions, most people don't know how to use threads, but it doesn't
stop them from thinking it is the Second Coming).

I'll refrain from posting again in this thread, unless you guys ask a direct
question.