lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
From: pauls at (Paul Schmehl)
Subject: Coding securely, was Linux (in)security

--On Sunday, October 26, 2003 7:25 PM -0800 Chris Eagle 
<> wrote:
> That is the most backward thing I have ever heard.  So you are saying all
> I need to do as a programmer is tell you not to pass a negative
> number/null pointer/un-initialized value... to my function and I am off
> the hook.  All I can say is that I am glad utdallas doesn't have you
> teaching programming. The fact that you are unaware what lies inside the
> black box in no way relieves the responsibility of the designer of the
> black box to make sure that it behaves predictably under all input cases.
No, that is not what I'm saying.  What I'm saying is that the programmer 
should not *expect* the subroutine to do his error checking for him.  If 
*everyone* wrote code that way, including the writer of the subroutine, we 
wouldn't have the problems we have with buffer overflows.

The problem we have now is everyone is expecting someone *else* to do the 
error checking, when in fact everyone should be expecting exactly the 

However, what you are expecting the writer of the subroutine to do is 
anticipate every possible input, and that may not be possible in all cases. 
Certainly the writer should do error checking, but that doesn't alleviate 
the *user* of the subroutine from doing their job.

Paul Schmehl (
Adjunct Information Security Officer
The University of Texas at Dallas
AVIEN Founding Member

Powered by blists - more mailing lists