❦ 4 septembre 2015 09:32 +0100, Neil Williams <codehelp@debian.org> :
[Applying patch to pre-minification source]
>> This will become more difficult with jQuery 3.x (due to ES6 to ES5
>> transformation). But manual adaptation should stay straightfoward
>> ("transpilation" only does local transformation).
>
> Are there supported tools which could prevent that difficulty becoming
> a problem?
None that I know of. Note that currently, the problem is quite
theoric. I don't know when jQuery 3.x will be released. I don't think
this will happen soon (but I am quite exterior to this community and not
a real jQuery user myself).
>> That's why I consider this pre-minification version as valid source
>> code.
>
> That indeed would support a usable security fix - thanks.
Great!
>> >> I agree. And doing from pre-minification source to minified source
>> >> is possible with the tools in main (uglifyjs or yui-compressor).
>> >
>> > Not in a way that reproduces the same .min.js as the original
>> > source - unless that is from a package already in Debian and the
>> > same minifier is used (with the same options).
>>
>> Getting the same min.js is not a goal (we don't try to get the same
>> binaries than upstream from source code in any other language, for
>> example in Go where upstreams like to provide binaries). Not adding
>> bugs would be nice, yes, but the situation is improving upstream (see
>> above). --
>
> OK. In that case, it might be worth embedding upstreams testing with
> using uglifyjs on the unminified JS files included upstream and seeing
> if there are (functional) bugs introduced by using that minifier.
That would be quite difficult if we are still in the context of
upstreams embedding their own copy of jQuery. First, some upstreams
don't have any JS-based tests (notably if JS is only an
accessory). Second, when they have them, they are unlikely to cover
jQuery use. Third, I really don't know if they are easy to run. Looking
at Wordpress, I see they need Grunt, but maybe having only qunit would
be fine.
I would be inclined to say "let's see if we get bug reports due to the
minification". I didn't run into those myself. Pau did, but it was quite
some time ago.
> What are the problems likely to be if Debian was to recommend/require
> that:
> "minified javascript is not to be regarded as source code suitable for
> supporting security fixes and needs to be rebuilt from unminified source
> code or replaced with symlinks to minified javascript provided by other
> packages, with dependencies added on those packages. When packages need
> to minify embedded Javascript which is not already packaged in Debian,
> only <foo> minifier should be used and any minified javascript files
> included by upstream must be replaced using the output of <foo>
> minifier."
I am not an expert enough to say that uglifyjs is really the minifier to
go. I would say that this is the most popular one, but that's really
just a hunch. Maybe some input from the Debian Javascript Maintainers
would help.
But I am OK with the idea.
> This excludes the issues of packaging of libjs* packages themselves
> (where the same minifier as upstream is likely to be a significant
> advantage in updating the package) but does provide a solution for the
> actual security concerns of packaged minified Javascript. A handy tool
> to do this would be useful as that would allow interested upstreams to
> test the effects of such a minifier before the upload to Debian.
>
> dh_uglify?
If there is some consensus that pre-minification source code is accepted
as valid source code by DFSG, I could help to get that.
--
Writing is easy; all you do is sit staring at the blank sheet of paper until
drops of blood form on your forehead.
-- Gene Fowler
Attachment:
signature.asc
Description: PGP signature