Re: Theo chiming in on strlcpy

[matthew sporleder <msporleder%gmail.com@localhost>]

On Sun, Dec 22, 2013 at 6:33 AM, Marc Espie <espie%nerim.net@localhost> wrote:
> 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.


I agree that these functions should be added to glibc and/or POSIX
and/or C2099 (or whatever).

Thanks for the amusing thread.  :)