The environment with which I am most familiar is VMS, and tradition
is what guides secure interfaces. Inner mode code _must_ probe any
arguments provided from an outer mode, probe the buffers specified
by descriptors provided, etc.
What do you do when you're handed a bad pointer?
I forget
ljknews wrote:
At 11:38 AM -0700 7/13/04, Blue Boar wrote:
ljknews wrote:
The environment with which I am most familiar is VMS, and tradition
is what guides secure interfaces. Inner mode code _must_ probe any
arguments provided from an outer mode, probe the buffers specified
by descriptors
At 10:39 AM -0700 7/14/04, Blue Boar wrote:
ljknews wrote:
At 11:38 AM -0700 7/13/04, Blue Boar wrote:
ljknews wrote:
The environment with which I am most familiar is VMS, and tradition
is what guides secure interfaces. Inner mode code _must_ probe any
arguments provided from an outer mode,
Peter Amey wrote:
Yes, the posit and verify approach. We adopted this because we think there
are problems with refining specs into code. One problem is that there can be
(usually will be) more than one valid way of implementing a spec. For example,
the spec may make the abstract assertion
Does anyone have pointers to articles on designing API's so
that they are
easy to use securely?
Not specifically related to security, but
http://www.cafeconleche.org/XOM/designprinciples.xhtml#d0e161 is one of the
better things I've seen about designing APIs.
Nick
ljknews wrote:
The environment with which I am most familiar is VMS, and tradition
is what guides secure interfaces. Inner mode code _must_ probe any
arguments provided from an outer mode, probe the buffers specified
by descriptors provided, etc.
What do you do when you're handed a bad pointer?
David Crocker wrote:
Crispin Cowan wrote:
The above is the art of programming language design. Programs written in
high-level languages are *precisely* specifications that result in the
system generating the program, thereby saving time and eliminating
coding error. You will find exactly those
At 3:55 PM -0700 7/10/04, Crispin Cowan wrote:
However, I think I do see a gap between these extremes. You could have
a formal specification that can be mechanically transformed into a
*checker* program that verifies that a solution is correct, but cannot
actually generate a correct solution.
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]
Behalf Of ljknews
Sent: 12 July 2004 14:24
To: [EMAIL PROTECTED]
Subject: Re: [SC-L] Programming languages used for security
At 3:55 PM -0700 7/10/04, Crispin Cowan wrote:
However, I think I do see
such storage mechanisms themselves, and insecurely at that.
My $0.02 or equivalent in local currency.
--Jeremy
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]
Behalf Of der Mouse
Sent: Friday, July 09, 2004 4:18 PM
To: [EMAIL PROTECTED]
Subject: Re: [SC-L] Programming
To get REALLY back to the point, I'd like to comment on Fabien's comment
that In my opinion, it's the most important things for a languages,
something to easily validate user input or to encrypt password are a must
have. Fabien is right, but increasingly that's only half the problem.
There
Dana Epp wrote:
My what a week of interesting discussions. Lets end this week on a
good and light hearted note.
Insert various analogies between programming languages and automobiles
here :)
* $MY_FAVORITE_LANGUAGE is like a $REALLY_COOL_CAR, while
$YOUR_FAVORITE_LANGUAGE is like a
David Crocker wrote...
I think there are two other questions that should be asked before
trying to answer this:
1. Is it appropriate to look for a single general purpose programming
language? Consider the following application areas:
a) Application packages
b) Operating systems, device
My what a week of interesting discussions. Lets end this week on a good
and light hearted note.
Admit it. We all know the most secure programming language is Logo anyways.
HLNIt's hip to be 'rep 4 [ fwd 50 rt 90]'/HLN
Laugh. Or the world laughs at you. Have a good weekend guys.
Crispin Cowan
Crispin Cowan wrote:
The above is the art of programming language design. Programs written in
high-level languages are *precisely* specifications that result in the
system generating the program, thereby saving time and eliminating
coding error. You will find exactly those arguments in the
Wall, Kevin wrote:
My vary reason for posing these questions is to see if there is any
type of consensus at all on what mechanisms / features a language
should and should not support WITH RESPECT TO SECURE PROGRAMMING.
For example, you mentioned garbage collection. To that I would add
things like
Programs written in high-level languages are *precisely*
specifications that result in the system generating the program,
Whilst I agree that the distinction between specification and
programming languages is not completely clear cut, there is
nevertheless a fundamental difference between
David Crocker wrote:
Whilst I agree that the distinction between specification and
programming languages is not completely clear cut, there is
nevertheless a fundamental difference between specification
and programming.
In a programming language, you tell the computer what you want
it to
I think the discussion regarding the thread
Re: [SC-L] Education and security -- another perspective
(was ACMQueue - Content)
is in part becoming a debate of language X vs language Y. Instead,
I'd like to take this thread off into another direction (if Ken
thinks it's appropriate to
At 8:49 AM -0500 7/9/04, Wall, Kevin wrote:
If a GENERAL PURPOSE programming language were designed by
scratch by someone who was both a security expert and
programming language expert, what would this language (and
it's environment) look like?
More specifically,
+ What set
Hello,
I'm not a secure coding expert, so my point of view is more from a
developper view.
+ What functionality should the accompanying libraries support
(e.g., encryption, access control, etc.)?
In my opinion, it's the most important things for a languages, something
to easily
ljknews wrote:
Such typing should include specification by the programmer of the range
of values allowed in variables: -32767 to +32767, 0 to 100, 1 to 100,
Characters a-z only, characters A-Z only, -10.863 to +4.368, etc.
The language should also support exact specification of arithmetic
I think there are two other questions that should be asked before trying to
answer this:
1. Is it appropriate to look for a single general purpose programming
language? Consider the following application areas:
a) Application packages
b) Operating systems, device drivers, network protocol stacks
David Crocker wrote:
1. Is it appropriate to look for a single general purpose programming
language? Consider the following application areas:
a) Application packages
b) Operating systems, device drivers, network protocol stacks etc.
c) Real-time embedded software
The features you need for these
24 matches
Mail list logo
