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

Re: Security concerns with minified javascript code



On Thu, 03 Sep 2015 22:51:50 +0200
Vincent Bernat <bernat@debian.org> wrote:

>  ❦  3 septembre 2015 13:19 -0700, Nikolaus Rath <Nikolaus@rath.org> :
> 
> > 2. Many javascript packages cannot be build from source with the
> > tools in main.
> 
> This is the one I don't agree. For me, pre-minification source is
> source code. If you show the pre-minification version of jQuery, many
> people will believe this is a valid source code (original comments,
> variable names and indentation are here).

... except that what you are referring to there is the "source" as it
appears as an unminified JS file on the filesystem after the upstream
code is packaged by Debian. The JQuery upstream is a set of directives
to include other snippet files which are then further processed into
both the unminified JS that looks like source code and the minified JS
which tends to get used by applications. The "source code" that
everyone talks about is actually not edited by anyone, least of all
upstream, it not used by applications (which embed the .min.js) and it
is not convertible to the source for modification used by JQuery
upstream, so patches to that are of no use to fixing security bugs in
JQuery as packaged in Debian.

JQuery in Debian *does* build from upstream source using only tools
available in Debian main. What it builds from is not usable to
applications, but if a bug is reported in the minified or unminified
JS, the maintainer (together with the JQuery upstream) can prepare a
patch to the source code that is built in Debian to produce a change in
the minified and unminified *generated files* for other applications to
use.

Patching an unminified JS file as it exists on the filesystem from
packaging doesn't actually help anyone, except possibly in debugging the
security hole. Even then, one of the more serious problems with
minification is that it isn't just a process of removing comments and
whitespace, the minifier can inject bugs which are not present in the
unminified version. Using a different minifier can introduce *different*
*unknown* bugs that only affect the version patched to "improve
security".

We really need to think of minifiers as transformational - these are
compilers in many ways.

For those upstreams who have to embed JS not available in Debian, then
the upstream code often cannot be processed in Debian, neither can the
unminified JS be minified into the same .min.js file as embedded due to
a lack of tools in Debian. In that sense, the current lintian
requirements are a hindrance and a mess because they require the
embedding upstream to include "source code" which cannot be converted
to the actual running code using tools in main in a reproducible
manner. Using a different minifier results in an untested and
unverifiable .min.js with no assurance that new bugs have not been
introduced.

This thread isn't principally about how JS packages already in main
actually get built and patched, this is about how upstreams who need to
embed JS not available in Debian can support security fixes to
javascript. Patches which produce a third form of the code which
produces a diff to the buggy version that is massively larger than the
security fix itself will not find favour with the release team or
security team during a release freeze.

The maintainers and upstreams of such packages *need* Debian to come up
with an answer for how their code needs to handle security fixes within
Debian. A way that produces a minimal diff to the released version to
make it practical to review the change to a package already in stable.
A way that absolutely does NOT introduce new bugs. A way that is
exclusively possible using tools available in Debian main. Can we
*please* talk about that now? Please don't leave this until the release
freeze for Stretch is on the horizon. This thread has gone on for ages
with bike-shedding, tippy-toeing around DFSG sidelines and insane ideas
about non-free but with no useful output for those who are actually
trying to fix the *SECURITY PROBLEM*.

There is a fundamental misconception in a lot of these discussions
which drops embedding upstreams right in the toilet. There is a real
problem here and it has nothing to do with whether packages go into
contrib or non-free. It is whether packages embedding javascript can
have sane security support in any part of Debian. Moving stuff to
non-free is *not* a security fix!

The core problem is *not* about legality or "preferred source for
modification" or the DFSG or a move to contrib/non-free - those are
(large) complicating factors. The core problem is how to fix
undiscovered security holes in packages already in Debian stable which
need to embed JS not available in Debian. This is a technical and
packaging problem, not a licence or legal one. We're taking about the
*security* of free software, not whether it is free or not.

> > 3. Software that cannot be build from source with the tools in main
> >    must not go in main but into contrib
> 
> 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).

Unless we solve the problem of being able to apply security fixes, the
location of the package within the archive is completely irrelevant.

-- 


Neil Williams
=============
http://www.linux.codehelp.co.uk/

Attachment: pgpDzelHoYRSH.pgp
Description: OpenPGP digital signature


Reply to: