On Fri, 04 Sep 2015 17:54:30 +0200 Vincent Bernat <bernat@debian.org> wrote: > ❦ 4 septembre 2015 09:32 +0100, Neil Williams > <codehelp@debian.org> : > > [Applying patch to pre-minification source] > >> 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. I was thinking primarily about my own upstream at that point, i.e. somewhere where there are staging or test services available with real data and users etc. but which are not used for important stuff. I want my own upstream to be confident that the javascript in the release is both tested before release and fixable after release. We don't have JS specific tests but we do have test boxes with a representative dataset to test all relevant use cases. That's the thing with embedding upstreams, the software has to do so many other things, the JS is a helper. > > 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. I'm no javascript expert either, far from it. I can see how these ideas can fix the distribution problems but whether the changes would introduce new bugs which the embedding upstream may be unable to reproduce without adopting the same process themselves, only time will tell. > > 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. The manpage for such a thing should be clear that it is meant for packages which need to embed JS which is not available in Debian, not for packages which are primarily or solely javascript. Maintainers of javascript packages could be recommended to use a minifier and build system which is compatible with the upstream for that package so that upstream fixes and Debian patches can be integrated smoothly. It just needs to a) remove the .min.js from the debian/*/ directories specified b) ensure the specified .js file exists c) uglify it and write that in place of the .min.js and d) fail if any unrecognised .min.js are left at the end. I'm happy with a statement in Policy that *binary* packages must not include minified javascript which has not been handled by dh_uglify, once it exists. If there is a suitable lead time, then new source package uploads could also be prohibited from containing minified javascript. I'm still unsure that pre-minification source code should be accepted in all cases, but I'm happy if pre-minification *with a recognised minify service* is the accepted way to handle the security concerns around embedded javascript. To be accepted for everything, pre-minification would need to be "easily" convertible back to the format used for modification by the maintainers and/or upstream of the javascript package in all cases. With embedded copies, there is no javascript upstream (at least as far as main is concerned), so the pre-minification source code is going to be what the embedding upstream are maintaining. I'd expect that embedding upstreams (certainly the one with which I'm involved) will drop .min.js from the released tarballs and adopt whatever is deemed the suitable minifier for all upstream testing. We don't want to be testing or releasing stuff which distributions replace with something else. It would be nice to be able to minify the javascript written by the team themselves too, to see if that has any performance benefit. Simon? you started this thread - if you're still reading, how is the above as a start point towards resolution? Dmitry? Do we have something which can find agreement out of this enormous thread? -- Neil Williams ============= http://www.linux.codehelp.co.uk/
Attachment:
pgpId3wjOPPPs.pgp
Description: OpenPGP digital signature