26-Apr-2024 04:36 GMT.		 UNDER CONSTRUCTION
Anonymous, there are 3 items in your selection
[Rant] Rant: Design articles for the usual suspects...ANN.lu
Posted on 09-Dec-2002 05:40 GMT by Joe "Floid" Kanowitz3 comments
View flat
View list
I'd wanted to introduce these with a little more commentary, but given the sheer quantity of "April good?" "April bad?" / "AmigaOne good?" "AmigaOne bad?" posts, these might be welcome distractions, and suitable for parties on either side of the fence.

Thus, here are links to mbac's "Peon's Guide To Secure System Development", and Ka-Ping Yee's "User Interaction Design for Secure Systems," both interesting reads- and both recently Slashdotted, if they look familiar. Okay, less of an elaboration than a note, here; my rationale in waving mbac's article around is to note that, if *anyone* should be able to assemble modular components into a secure system (or understand the HURD ;)), it'd be an "Amigan..." (It also demonstrates some fragment of the 'real world's' approach to 'safe' languages.) ...and I must admit I still haven't been able to read Yee's full paper myself (see why this is a 'rant?'), though the summary, at least, is something everyone should have a look at.
Rant: Design articles for the usual suspects... : Comment 1 of 3ANN.lu
Posted by Paul H on 09-Dec-2002 13:33 GMT
I feel that the first paper "Peon's Guide To Secure System Development" is a little hard to take seriously. It has some important points but does not offer many clear or balanced arguments for the statements it makes (it reads more like a rant than a structured paper). I don't think he will manage to shame many developers to write more secure applications with this approach.
I agree to some extent with his views concerning security not being limited to cryptography, with the ability to control and understand what the processes of what your OS is performing. But his section mentioning that it is a crime to teach C/C++ and that we should be all using high level languages to achieve our programing goals is nonsense.
Prehaps high level languages should be someones first point of call when developing a new project, but the idea of teaching someone lower level languages is that they develop an understanding of how a system operates at a closer level to machine level. The problem is not that C/C++/ASM shouldn't be taught, it is knowing how and when to use these languages appropriately. With lower level langauges comes more responsibility. Old Amiga coders bashing with hardware registers directly will know of the consequences of manipulating registers, pushing data onto the stack etc... The lower the language the more responsibility falls onto the programmer - this is what needs to be taught. Respect the system.
The section on Middleware is a little over the top. He says, "Developers want it because.. uh.. You’re not quite sure.". Well I say that middleware can ease the development of a system and reduce the amount of time it takes to develop it. It is important that you understand what the middleware does exactly and be aware of issues regarding it. You wouldn't normally write your own interface to link in with a data source when you can use a supplied ODBC connection driver would you? Yes be smart as the author said, but taking time and reinventing the wheel in every instance can often cost you as opposed to tried and tested available solutions.
Portability is a good thing - I agree.
Just my 2 cents worth. Right, enough - back to work :)
(Haven't had time to look at the other paper, but it looks better and I'll read it on my way home tonight.)
Rant: Design articles for the usual suspects... : Comment 2 of 3ANN.lu
Posted by Anonymous on 09-Dec-2002 20:40 GMT
I have read the codingstyle.txt that he link to:
I can find little revelers to pointer and stuff like that in that text,
I prefers making global functions to reserve and free dynamic structures.
about the codingstyle.txt document it
mostly about how to format your C source code,
and commenting, refers to doing
if (this is true) {
}
instead of
if (this is Tues)
{
}
I this this is C bullies stuff.
otter parts about splitting function up i do agree with it,
the fact is, that it's required.
How have not made old Basic programs
run out of ides when naming variables?
have global and local variables,
global variables should only be variables you most have it out side.
you should all sow group them, so you Se what they are for.
struct typedef
{
int x;
int y;
int w;
int h;
} view_type;
view_type *view_thing;
and about copy and paste program place do not do this, it only make your
programs big, try moving the code out side to an sparest function(),
your code will look better and when you optimize / debug your sub functions,
every part of your programs gets an "speed increase" / fix.
Rant: Design articles for the usual suspects... : Comment 3 of 3ANN.lu
Posted by alan buxey on 12-Dec-2002 12:37 GMT
In reply to Comment 1 (Paul H):
..the main issue , dealing with secure code, about middleware and
usage of external libraries is that suddenly the security of
your code is then compromised by any problems with that 3rd-party
code (unless you've got the source for it and decide to check and
fix it yourself...).
eg, straight to mind comes the zlib issue on unix. theres tons
of statically/dynamically linked code to the compression library
that are now insecure...many of those being internet apps. oh great!
couple this with the fact the bug is on almost EVERY worldwide platform
and you hope things really dont rely on a ubiquitous middleware code
so much.
Anonymous, there are 3 items in your selection
Back to Top