RE: [SC-L] Opinion re an interesting article on Linux security in Linux Journal

> > > To secure a machine from malware introduced by a naive user it is > > required that naive users not have the privilege to introduce > > software that can be executed by them or by other naive users. > > I would disagree. There's nothing wrong with allowing naïve users to > introduce softwa

RE: [SC-L] Dot Net guidelines?

> > Hi All, > my boss has asked me to see if there are any guidelines out > there regarding > dot Net... > > We currently use Java, but we expect the development teams to > want to use > microsoft's lastest toy sooner or later.. > > Thanks, > > Bret >

RE: [SC-L] Programming languages used for security

> > 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

RE: [SC-L] Programming languages -- the "third rail" of secure coding

> I'd also point out that if it's languages you're trying to list, > JavaScript arguably should not have a separate entry from Java Yes it should - they are substantially different languages, even if we look at them only syntactically. You could argue that Javascript should be listed as ECMAScri

RE: [SC-L] Programming languages -- the "third rail" of secure

> >IMHO, though, any such effort is pointless. The reality is > that we're going > >to be stuck with C/C++, Java, C#, FORTRAN, COBOL, and various > >interpreted/scripting languages for a very long time. > Rather than argue > >about what makes something good/better, we'd be better off > figuri

RE: [SC-L] Programming languages -- the "third rail" of secure coding

> >Java/C#: Reasonably safe (both provide protection against > buffer overflows, > >are type safe and provide built-in security mechanisms) > >FORTRAN/COBOL: Don't know - my impression is that COBOL is > fairly safe > >Scripting Languages: Depends on the language. Lack of type > safety can be a