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]
