From: Peter Dimov (pdimov_at_[hidden])
Date: 2005-07-07 08:23:44
Martyn Lovell wrote:
> Hi everyone,
>
> I wanted to take a few moments to address the range of points raised
> in this thread, and to provide a little background.
>
> Herb provided a great summary of our motivations here. We want to help
> developers write more secure code, and we want to do that by default,
> so that the out-of-the-box experience is as secure as we can make it.
> We've reviewed lots of code in the last few years as part of the intensive
> security focus at Microsoft. Though we've already used these lessons
> to secure our own code, we wanted to help them be applied to other
> code too.
>
> To make this happen, we added "deprecation" warnings to a bunch of
> standard APIs. Most warnings tell you what function to use instead.
> For example, the warning for strcpy will point you at strcpy_s, which
> takes a buffer size as a second parameter. As you can imagine these
> kinds of changes mostly impact the C standard library.
I haven't looked at VC8 for a while, but last time I looked, the deprecation
warnings were entirely useless for one simple reason: a single "deprecated"
warning was used for gets, strcpy, and fopen (!).
The only thing this deprecation campaign achieves is to de-value the warning
and make the decision to turn it off a no-brainer.
A more sensible approach would be to define a new class of "deprecated for
security reasons" warnings. "Guaranteed buffer overflow", "potential buffer
overflow" and "overflow-safe with potential subtle security implications"
should be separate warnings that can be switched on/off independently.
The choice between portable but "deprecated" and non-portable but secure
isn't very appealing either, but that's a separate issue. I'd prefer the
undeprecated version of sprintf to be snprintf instead of sprintf_s, and the
undeprecated version of swprintf to be swprintf (the standard version of
which wasn't insecure, only the Microsoft nonstandard variation was.)