Berin, as I read through this reply, I realized that I have been using the name Avalon to refer to the Framework and Excalibur, when Avalon really refers to a set of projects, including Phoenix, Framework and Excalibur. What I'm concerned with is the application of those rules to Framework and Excalibur. Not Phoenix.
I'll start with Rule 12: Secrets stored in your code won't protect you This rule introduces hostile JVMs. I will simply give up against those - if the JVM is insecure, I see no way to make Excalibur/Framework secure. Rule 1: Some extra code to type, but no problem overall. I have no problem with this rule. Rule 2: Makes extension of classes and thus code reuse difficult. Rule 3: Makes code re-use difficult. Rule 4, 5, 6, 7: No problem with this. Rule 8: Makes extension of classes and thus code reuse difficult. Rule 9, 10: Kills application of Excalibur/Framework in a distributed environment. Rule 11: No problem. Basically, my gripes with the article boils down to the fact that many of the rules will result in a non-extendable framework, which is a bit of an oxymoron to me. The 9th and 10th rule is especially irritating, as I mainly do work in a clustered environment. The question is, is Excalibur/Framework designed for Phoenix, or as a general purpose library? If it is designed for Phoenix, then it should be hardened as described by the rules given. If not, I believe that the loss of extensibility caused by the rules will make Excalibur/Framework unsuitable for general-purpose use. Which means that we'll be back to each-project-having-its-own-framework-etc. and you know that kills security fast. So - would it be possible to restrict the hardening to Phoenix, leaving the framework open and unsecure? I think this will save the framework from being commited to a very small target, and allow Phoenix to be as secure as possible. > I deal with customers who are very protective of their > data--which makes it my business to be protective of their data too. > I urge you to do your own research. Security by design is more difficult, > but when you are developing a server framework it is mission critical. Agreed 100%. But should that go into the framework/Excalibur or into Phoenix? /LS --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
