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

Re: Security concerns with minified javascript code



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: pgpO59ebaeziy.pgp
Description: OpenPGP digital signature


Reply to: