Grzegorz,
The most important part of proposal - multiple plugins directories
counted explicitly in trac.ini and I guess it has minimal impact.
i.e. we can have something like
plugins_dirs = /a,/b,/c
plugins_autoenable_dirs=/a,/c
and keep everybody satisfied ;)
(see also below)
On 2010-10-11 15:45, Grzegorz Sobanski wrote:
Currently nothing prevents admin of other project enable it for its
own env.
Hmm, just put in in envdir/plugins?
Then it's not available to other environments.
Unless someone "inherits" it ... There are some symlink/permissions
tricks that solve this problem, but I would like to see an instant
solution rather than tricks.
Again, if someone already has R/W access to the env folder, you have
bigger problems.
e.g.
A plugin developer type: cp myplugin.py myplugin_old.py
and than forget to delete myplugin_old.py with plenty of debug
printing.
And what if he types: rm *?
rm * is not an issue as it doesn't lead to security whole. Just some
extra work for backup team.
Also how often you here that someone did rm * on the hosting ? Incident
with forgotten old or back files happens once a month and cost a fortune.
Etc, etc
As Noah said, if someone has fs access, or can deploy plugins developed
by themselves, they can break everything.
2. No autoenable
This just makes life difficult for simple, one-env sites.
Really? It's either one-line in ini file or couple of mouse clicks in
admin panel.
A would say: sensible defaults.
If someone puts a plugin in environment, he surely wants it enabled,
so IMO it should be enabled by default. It's a very sensible solution.
It's very sensible solution for small system where plugin developer,
trac admin and web qa is the same person.
Debugging issues like one with myplugin_old.py above eats much more
time.
But only for you, and enabling all modules would have to be done by
hundreads of other people, sorry. Plus all the questions on ML "why my
plugin doesn't work".
We should separate trac core (i.e. controlled and supported by trac
team) information from one provided by third-party, untrusted plugins
to
avoid possible conflicts and save support efforts.
Trac doesn't sandbox plugins, so you *have to* trust plugins, because
they can do everything.
Yes and it's a trac design issue. But it couldn't be addressed without
significant efforts, ini separation is just one simple step forward.
I don't see how separating enabling modules from trac.ini helps with
anything, sorry.
Trac is clearly devided into core and plugins and it's one of biggest
advantage of trac. i.e. if I turn off all plugins I have reasonable and
secure enough environment.
But bad plugin (e.g. with incorrect implementation of
IAdminPanelProvider) could destroy whole project configuration
I think you may have some valid points about probles in config like
"trac farm", but the proposed solution IMO are not good defaults for
trac, at least some of them.
I never pretend to be an oracle .. Just giving to trac community a
subject to think.
-Dmitry
--
Dmitry Samersoff
[email protected], http://devnull.samersoff.net
* I do want to change the world, I don't want the world to change me
--
You received this message because you are subscribed to the Google Groups "Trac
Development" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/trac-dev?hl=en.
