[sr #107522] Use of dangerous/banned functions

[Jeffrey Walton]

Follow-up Comment #5, sr #107522 (project gnutls):

Hi Simon,

I'm going to field things out of order to improve the flow of responses.

> The strlcpy etc are as criticized as the strcpy functions... 
I have also read the counter arguments, which I am going to paraphrase below.
The arguments are generic, and not specific to strcpy_s (and friends) or
strlcpy (and friends). Please feel free to correct or expand my compilation
below.

: There are two major issues with using the safer
: string functions:
: (1) The replacement functions do not completely solve the
: "unsafe" handling inherent in the original functions.
: (2) The replacement functions are slower than the original
: functions under some circumstances and implementations.

To re-frame the arguments above, consider: you are a junior programmer making
$20 hour (an unsafe function). You want to be a project manager making $60
hour (a safe, efficient, replacement function). Sometime in your career, you
are offered a senior programming position at $40 hour (a safer function). But
you reject the offer since its not the position of program manager.

== Item 1 ==
Does it make sense to reject the $40 hour position? Does it make sense to
reject the safer functions because they were *only* designed to be a [near]
drop in replacement to help remediate issues in the existing code base?

I believe the syndrome is colloquially referred to as, "throwing the baby out
with the bath water".

== Item 2 ==
The B programming language made its debut circa 1969. C followed from B in
the 1970s. strcpy and friends made their debut nearly 40 years ago!

Unfortunately, it took less than 40 years for the environment, which was
originally benign, to turn hostile or toxic. The Dataloss Database
(http://datalossdb.org/) is testament to the fact.

"They who can give up essential security to obtain a little temporary speed,
deserve neither security nor speed."
- Benjamin Franklin, circa 1775

== Item 3 ==
Item 3 did not make the list, but it always plays a role in matters such as
these: political feasibility.

Microsoft sponsored the initiative at ISO/IEC. The "initiative" was
"Extensions to the C Library Part I: Bounds-checking interfaces". This is also
known as "safer string handling functions". It is now a normative part of the
current C1X draft (latest version dated 2010-10-04).

The initiative was accepted and originally presented as a Type 2 Technical
Report, which means "there is the future but not immediate possibility of an
agreement on an International Standard".

The take away: Item 3 is "sour grapes".

> ...decisions within gnulib to not provide portability
> wrappers for them because it is not a good idea
This effect is "no support for safer functions". It is directly attributed to
(1) above.

In this case, what are the distributions, POSIX, or the Open Standards group,
et al offering for the complete resolution of the problems and issues
associated with the original [unsafe] functions? That is, what are the "safe"
functions (not "safer" functions)?

For portability via standardization, I'm willing to use a set of wrappers
which [the wrappers] call into safer functions.

> Do you have some concrete pointer to broken GnuTLS code?
Ah!!! It's not about a single instance of broken code. I don't want to fix 1
stack smash, or 1 buffer overflow for that matter. A particular stack smash or
buffer over flow is irrelevant in the big picture.

I want policies - which are transformed into procedures - that ensure all
stack smashes, buffer overflows, and other miscreants go the way of the
dinosaurs.

So the policy [which I prefer] is "secure, robust, efficient, and portable
code." One of the ways to make it happen is via a policy which requires all
project code to call through a wrapper, and then the wrapper calls a safer
function.

To summarize, it *is* about learning from the past, and moving forward in a
safe, robust, and efficient manner. Portability is icing on the cake.

Allow of this is technically feasible. Some of it is politically infeasible.

Jeff


    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/support/?107522>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/