Re: security audit

Will said:
...
> (1) Avoid executing methods on objects of type
> Class/ClassLoader, etc.

>

> Nathan make the excellent point that developers need to be able to
> turn this off or on.  I did this using a config property in my
> proposed patch, with the default ON.

some might argue the default should be off for backwards
compatibility, but i don't see either way as being a big deal.

> (For some reason the patch seems not to have been posted to the
> velocity-dev archives, so I'm going to resend it).

actually, why don't you post it in BugZilla? (be sure to check for a
duplicate/similar bug first)  that way it is less likely to be
forgotten.  otherwise, it is almost sure to end up buried in people's
inboxes or mail folders and eventually forgotten.  also, it seems
entirely hit or miss on attachments coming through to the list these
days.  i don't know what's up with that.

> as a matter of principle, I think that systems should generally ship
> with more stringent security enabled by default

a good point.

> I believe this is a critical issue for Velocity web developers

only for those who can't trust their designers.  it's not as critical
for the rest of us.  that's not to say it needn't be addressed, just
don't be surprised if you fail to generate a sense of urgency on the
matter.


> (2)  Event handler allowing developer to control resource pulled up
> by #include and #parse

> http://nagoya.apache.org/eyebrowse/ReadMsg?listName=velocity-
> dev@xxxxxxxxxxxxxxxxxx&msgNo=7781

>

> Nathan suggests this should be a custom directive.  As a
> contrasting opinion, I'd like to see this go into the Velocity core,
as
> it's a generally useful capability.

ah, i thought you were proposing to alter the existing directives, not
an event handler.  mea culpa.

to revise my stance, it sounds like you have a much better handle on
how best to implement it.  :)  as for whether it should be in the
core, i'll be +0 and let others decide.  i certainly don't need it
(configuring the resource loader path(s) works fine for me), but if
others really do find it to be "a generally useful capability," then i
sure won't protest.

> -- make an included file be relative to the current template.
(Easier
> for the template designer to understand as this is analogous to
> HTML href's)

this seems generally useful, but should probably be optional.

> -- when a resource is included from a particular pool of pages (e.g.
> a user web site), pull it from a particular location

> -- add user-specific permissions for included files
>
> The last one is the critical need.

yes, i can certainly see that it is quite critical for your
application/use-case.  i do not see this as being at all critical for
most others.  in fact, AFAICT, such a feature seems very specific to
applications like yours.

> As I noted in an earlier email, I have about 600 users who can
> create web templates and upload them into the same resource-
> space.   Maybe this is a special case.

i suspect so. :-/

Nathan Bubna
nathan@xxxxxxxx