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 provid
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 provide
>> 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
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 provided,
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?
der Mouse wrote:
This is not to say that moving up levels is worthless. But it sounds
to me as though everyone in this discussion is stuck in some kind of
mindset like "if we can just eliminate $CLASS_OF_ERROR, we'll have a
safe and secure programming language". We won't; we'll just have one
wher
> 1. Features that help avoid mistakes. Such features are valuable in
> all programming domains (not just security) and include things like
> strong typing, automatic memory management, few or no automatic type
> conversions. [...]
> 2. Features that help to make the program secure and robust fo
>
> 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
At 2:51 PM -0400 7/12/04, Jeff Williams wrote:
>Does anyone have pointers to articles on designing API's so that they are
>easy to use securely?
The environment with which I am most familiar is VMS, and tradition
is what guides secure interfaces. Inner mode code _must_ probe any
arguments provid
Crispin Cowan wrote:
>>
For years, I have been trying to get formal specification advocates to
explain the difference between high level programming languages and
specification languages. From my point of view, "formal specifications"
can be divided into two categories:
* Those that can be
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
Kevin Wall wrote:
>>
> 2. Do we need programming languages at all? Why not write precise
> high-level specifications and have the system generate the program,
> thereby saving time and eliminating coding error? [This is not yet
> feasible for operating systems, but it is feasible for many
> a
> 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.
> T
[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 languages used for security
>
>
> > 2. Do we need programming languages at all? Why not write precis
> -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
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 soluti
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 argu
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
>
>> 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 betw
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 s
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 pref
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.
It's hip to be 'rep 4 [ fwd 50 rt 90]'
Laugh. Or the world laughs at you. Have a good weekend guys.
Crispin Cowan wrote:
Davi
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
> 2. Do we need programming languages at all? Why not write precise
> high-level specifications and have the system generate the program,
> thereby saving time and eliminating coding error?
Then the "high-level specification" _is_ the programming language,
albeit a relatively unusual one, with th
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 Yugo.
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
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 stack
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
operation
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
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,
>
> + W
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
31 matches
Mail list logo
