Re: Re: 'Restricted' data, an additional security mechanism for Perl.

[flyingmoose]

The idea of restricted data is the same -- to provide a mechanism whereby programmers need to go to more effort in order to make a mistake.

This statement scares me. If this were true, and there were no programmers of any worth in the world, we'd need to throw away all of our C and assembler code right now. It's too easy to make mistakes. Nope, a good programmer tests his code, and better yet, has folks test his code for him. Shepherding is all well and good, but it is no substitute for education, analysis, and foresight.

If you can't trust the software you are running, then it's really a lost cause in all languages. A programmer who needs to write "use restricted variable yes I really mean it", can abuse this just as well as any other variable. In the real world, private access isn't there for security reasons, it's there for a much better reason -- locking an API down to enforce an interface.

Other languages that have private access can usually access private variables through either reflection/symbol-tables or native bindings (example: I can read & write private variables in Java using both reflection and JNI).

So, adding additional security 'features' into a language may only give a false sense of security, odds are that injection attack or cross-site-scripting bug is still there, as it's an algorithmic/implementation bug rather than a language issue.

Having security features can often be misleading. For instance, I know of a certain application that saves passwords BASE64 with world-readable permissions. I know of another that saves passwords plaintext. Local-socket exploits too. The language can't shield you from any of these, and often these sort of problems are the worst kind.

Security, essentially, is needing to know all of these things. They can't all be fixed in terms of language usage. It takes a very strong programmer to know what code is insecure and what isn't.