We bundle jquery, currently version jquery 1.6.2 and jquery-ui 1.8.14 (both from mid-2011).
These might be vulnerable to several CVEs, see outdated jquery-ui for one discussion. A glance at OpenCVE shows many more that might apply.
Relatedly, Debian would prefer we don't bundle it in the package, but stripping it out or referencing an external copy is non-trivial (as Joey outlines)
The APIs are broken between the versions we've bundled and the current versions (as smcv said in the prior linked page) so we can't just update the bundled ones.
To try and sort this out I think we should review what we're using from Jquery, and determine what the best choice is for that functionality in future (which might be to continue with jquery and jquery-ui).
— Jon, 2025-08-27
loginselector
(no doc page) uses jquery.
There's a tiny use in templates/login-selector.tmpl
which could easily
be substituted for a longer, standard DOM method of finding the fieldset
.
The remaining use is in
underlays/login-selector/ikiwiki/login-selector/login-selector.js
, which
calls extend
once, and is otherwise just accessors. So for loginselector
,
it would be easy to remove the jquery dependency.
attachment uses jquery.fileupload.js
, jquery.fileupload-ui.js
,
jquery.iframe-transport.js
, jquery.tmpl.js
and jquery-ui.js
. I think
it would be much harder to remove or replace. (I'm at the limit of my JS
knowledge here.)
However, if it was the only user of jquery, we could at least move the jquery JS into the attachment underlay, adjacent to the other jquery-related JS, and not have a separate jquery underlay. It would be a small step forward, to sequester the stuff in one place. Or maybe a waste of time. I don't know!
— Jon, 2025-08-28
Doesn't feel like a waste of time to me at all: reducing the blast radius is a great idea, imho, but it might cause problems for third-party plugins that assume jquery is present... maybe that's where it's more of a problem? maybe a progressive deprecation? -- anarcat