On Sun, 15 Nov 2015 11:42:31 +1100 Brian May <b...@debian.org> wrote:
> Neil Williams <codeh...@debian.org> writes:
>
> >> E: python3-ajax-select: privacy-breach-uses-embedded-file
> >> usr/lib/python3/dist-packages/ajax_select/static/ajax_select/js/bootstrap.js
> >> You may use libjs-jquery-ui package.
> >
> > You may indeed - replace the file with a symlink in debian/rules and
> > add to Depends.
>
> Replace what file with a symlink? bootstrap.js isn't the problem
> itself, the problem is bootstrap.js referencing jquery.min.js from an
> external source. The library itself doesn't currently come with a
> copy of jquery.
So the reference to bootstrap.js needs to be patched out to refer to a
static location which can be put in place using a Depends in
debian/rules.
To get this upstream, yes, upstream should include jquery because that
way everyone knows which version of jquery upstream is actually using.
See below, there is a script which could help here, using node-uglify.
> In this case the python*-ajax-select packages are not intended to be
> used by users, rather they are libraries intended to be used by other
> applications (Django apps) which are used by users. There simply
> isn't a single standard way I know of providing and using one and
> only one jquery in Django libraries. (no - Django Media objects don't
> help)
So the upstream tests against random jquery versions across a wide
range? Isn't it more likely that upstream have a particular version of
jquery that gets used and tested.
> Maybe I should raise this issue with the Django developers? Even if I
> did, came up with a proposal (I don't have one), and we agreed to a
> solution, we still need a solution for now, with the current release
> of Django.
Upstream changes will take time, yes. That's unavoidable.
> If I tell upstream to include a copy of jquery.min.js and/or jquery.js
> in the static directory (this is another issue[1]), it will get
> exported in all Django apps that use this library, including those
> that don't need or want it.
Isn't bootstrap.js doing that already? If bootstrap.js is part of
upstream, using bootstrap.js brings in an external jquery.
> Maybe this is considered a reasonable
> tradeoff - it is unlikely to cause conflicts due to the directory
> name used, however I come from the school of thought that you
> shouldn't be publishing files unless there actually is a need to
> publish the files.
There is a need. If there is a security fix in jquery, how is your
package going to fix that CVE? You can't rely on some external content.
It needs to be fixable within the archive.
> Apologies if I seem argumentative, however I really don't see a good
> solution to this. The best decision really depends on the Django app
> that uses this library, and upstream have tried to make it easier to
> get started using the library in such a way it has minimal downsides
> for Django apps that want to include their own version of jquery.
Then maybe upstream should state the value of using a tested version of
jquery which can have security fixes applied. It sounds like upstream
have decided to support something which is actually counter-productive
and ill-advised on a security basis.
The best way is for upstream to adopt something like the script I
linked to last time. It allows upstream to use one JS set, provides a
way for packagers or others to replace bits of that JS set with
symlinks to preferred versions of that JS. What JS upstream do provide,
has all internal references resolved internally and is provided as
editable JS with all references to JS as .min.js, using a script which
does simple uglification in a configurable way.
We've only just merged that script upstream and it works for us - it
will likely need changes to work for others but we're open to patches
if people are interested.
> >> privacy-breach-uses-embedded-file - this is only correct if used
> >> by an application that does not import jquery symbols itself. If
> >> the application already has loaded jqueblry and jquery-ui from,
> >> say a local source, I believe there is no privacy issue:
> >>
> >> // load jquery and jquery-ui if needed
> >> // into window.jQuery
> >> if (typeof window.jQuery === 'undefined') {
> >> document.write('<script type="text/javascript"
> >> src="//ajax.googleapis.com/ajax/libs/jquery/1.9.1/jquery.min.js"><\/script><script
> >>
> >
> > That src can be patched to not look at //googleapis but to look at
> > {{ STATIC }}/blah/js/jquery.min.js which itself is a symlink.
> > Similarly with href. Work with upstream about the problems of
> > relying on third party sites for their code.
>
> Like I said above, that means upstream must provide jquery.min.js, and
> presumably we need a way to automatically build jquery.min.js from
> jquery.js. Seems a lot of work for something may get overriden and not
> used by the calling application anyway...
It's work that still needs to be done. Besides, the package - in Debian
- doesn't need to do the minification, jquery.min.js exists and can be
replaced with a symlink to the libjs dependency file. uglify is then
just called on what is internal JS or not yet packaged JS, effectively
adopted by upstream.
Upstream would be best providing jquery.js as this can be a vehicle for
security fixes, jquery.min.js cannot unless it's built from jquery.js
in VCS/release.
> [1] I guess upstream would need to include jquery.js and then build
> jquery.min.js in setup.py or something; not sure how you would do this
> actually, especially if you want to retain the ability to test the
> code from the source directory.
I provided links for scripts which do exactly this last time, these:
https://git.linaro.org/lava/lava-server.git/blob/HEAD:/share/javascript.py
https://git.linaro.org/lava/lava-server.git/blob/HEAD:/share/javascript.yaml
--
Neil Williams
=============
http://www.linux.codehelp.co.uk/
pgpq5m5s_MuPy.pgp
Description: OpenPGP digital signature
