[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: jQuery dependency for Trac 0.11 should be < 1.3



On Sat, Dec 26, 2009 at 2:08 PM, Paul Wise <pabs@debian.org> wrote:
>
>> Upstream Trac is shipped with jQuery it needs while leaving Genshi and
>> other libraries as dependencies. Debian specific patch removes jQuery
>> from Trac distribution even though it contributes only 2% to package
>> size. This dependency injection creates aforementioned problems.
>
> The dependency exists whether or not trac has "Depends: libjs-jquery".

This dependency is hidden, encapsulated inside of Trac application. If
you see jquery.js file inside of its source package - why not to leave
it alone - where is the Policy that requires to replace it with some
external copy? Does Policy take priority over common sense if the
change may affect application stability? The maintenance work in this
case creates more problems than benefits and may be not as
appreciated.

Coming back to Earth - what security holes are expected from jQuery?
What make people think that Trac developers won't release a new
version when such important security problem arise? Basically
everything you need is to track that Trac includes some version of
jQuery to respond to security issues. Possible response could be in
creating a patch to include different jQuery version until upstream
does the same, but this should be decided on case-by-case basis. You
insist on using Debian Package System to pull parts of application
automatically, and that requires manually dissecting application into
pieces and analyzing dependencies. That's because there is probably no
Security Scanner able to detect affected libraries in shipped
applications and create security issues automatically. What's the
value of Debian then if it takes security over stability with no
option to weigh one over other on a discretion of maintainer of
dependent package?

> Removing the "Depends: libjs-jquery" sounds like the equivalent of
> shipping a copy of GTK+ with gnome-terminal. Or a copy of ncurses with
> top. Or a copy of glibc with ls or cp.

It may sound like if you forget about size ratios of jQuery/Trac=2%
and GTK+/gnome-terminal=757%

> None of those things are
> nessecary, so why should shipping a copy of jQuery with one of the
> packages that use it be any different?

It is not necessary to do the extra job of removing jQuery liver from
the Trac body at all. The only advantage I see are security patches.
Anything else?

So far the potential security threat from jQuery shipped inside Trac
package doesn't worth the time for implementing measures to maintain
external dependencies, potential compatibility issues and restriction
for having a 1.3.x jQuery on a system with 0.11 Trac.

Seems like I finally made my point clear this time. :P

>> There are more than 200 plugins tagged for 0.11 on
>> http://trac-hacks.org/ They were developed and debugged with jQuery
>> 1.2.x which is not forward compatible with 1.3.x  I don't feel like I
>> want to check if they are compatible next time I'd like to use one.
>> 15kBytes doesn't worth wasted hours.
>
> It sounds like you're installing the trac plugins manually rather from
> Debian packages. I'd suggest manually installing jquery 1.2 for the
> manually installed plugins that need it and putting the javascript
> file at a different URL to the Debian jQuery 1.3 version. If there are
> any trac plugins in Debian sid/squeeze that need jQuery 1.2, I'd
> suggest filing RC bugs.

The problem that Trac is a web application and during web page
rendering plugins load and share all available JS code. When JS
behaves wrong - it is also not easy to spot. You don't get coredumps
or stacktraces or compilation errors. Your DHTML window may not popup
as expected, syntax hints may not be displayed, subscription link
won't be inserted where it should or hidden form field won't be
updated. In most cases you notice a change unless you're a developer
of a plugin and won't catch the error unless your users always browse
internet with opened JavaScript console.

Google Web Toolkit was invented not as some fancy tool for Java guys
who want to switch to ajax - it makes even experienced web front end
designers skillful in DHTML/JavaScript learn Java. Things in
JavaScript are already fragile enough, let's not make them worse. Bugs
from broken JS (and there is a lot of JS in 0.12) will be submitted by
users to Trac in 95% of cases - not to Debian. Trac developers will be
very happy to track bugs down to a wrong jQuery version that by their
assumption should correspond to a Trac release.

Well, it may sound a little exaggerated, but writing this is nothing
compared to the time it took to fix all problems in my Debian Trac
installation over sluggish SSH. There is nothing else to add.

-- 
anatoly t.


Reply to: