Christian Boos <[EMAIL PROTECTED]> wrote:
> The tradeoff between security increase/inconvenience was in favor of the
> security increase.
I totally understand this decision, and it is to be expected that
similar things will happen over and over again. No problem.
The problem is that Trac is excellent software, which is heavily
used by its users, and a variety of plugins does exist only a few
months after implementation of this mechanism. You can expect
the number of plugins to grow rapidly.
> The "nice" thing about this incompatibility is that plugin writers
> _will_ have to take notice of the change and make their plugin robust
> against XSS attacks too :)
Nice. :-) But perhaps there is a way of quality management that is
a bit more professional.
An idea is a thing as a list of "officially supported plugins", so that
the Trac release team knows the maintainers and can contact them
whenever some API changes etc. are to be expected. A new release can
then be able to guarantee that the officially supported plugins will
run with the new release. This subset of plugins could also be
distributed centrally. At least there could be a central status list.
Actually, the "officially supported plugins" seems to be the WebAdmin
plugin, and the release notes provided (incorrect, but nevertheless)
information on the need to upgrade WebAdmin. That was fine. Imagine
the plugin jungle to grow and the workload to check out if which
plugins need updates.
I guess this is worth thinking of.
gruß,
--
Lutz Frommberger | "Wenn ist das Nunstück git und
| Slotermeyer? Ja! ... Beiherhund
http://www.aussagekraft.de | das Oder die Flipperwaldt
pgp key on request | gersput." - Ernest Scribbler
_______________________________________________
Trac mailing list
[email protected]
http://lists.edgewall.com/mailman/listinfo/trac
