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

Re: Security concerns with minified javascript code

On Wed, 2 Sep 2015 13:33:57 -0400
Marvin Renich <mrvn@renich.org> wrote:

> * Ben Hutchings <ben@decadent.org.uk> [150902 10:12]:
> > My preferred form is a git repository of code written in C, Python,
> > or some other language I know.  That doesn't mean that a tarball of
> > Haskell code is non-free!

> No, "A preferred form" is what upstream uses.  The DFSG does not use
> the term "THE preferred form", and I believe that was wise.  There
> can be multiple "preferred forms" for some software, and all are, in
> my opinion, acceptable by the DFSG.  The real question is whether it
> is reasonable to expect someone who wishes to modify the software to
> consider the form "source".

Minified isn't source for modification, that much is as far as we've
got on consensus in this thread. However, lintian has had checks on
minified without unminified JS available for some time and embedding
upstreams can follow that, so there is source for modification which
the embedding upstream would be able to use but, likely as not, the
original JS upstream would not. Equally, fixing the unminified source
likely also means patching the embedding upstream templates to use
the updated unminified JS as the .min.js cannot be built in the same
way as the original JS upstream. There are other minifiers available
but those could introduce subtle new bugs.

Debian could mandate that embedding upstreams do not include .min.js at
all and I could live with that. It doesn't fix the problem that Debian
lacks a sane way of maintainers keeping javascript packages up to date
with javascript upstreams in ways that embedding upstreams can actually

The result of that is making software in Debian worse by having more
unminified embedded copies at different versions across lots of
packages, exponentially more security issues and more JS packages out of
date relative to the JS upstream. That would not be good.

Embedding software is a bad idea - Debian needs a way of keeping
javascript packages up to date with JS upstreams so that other
upstreams don't need to embed (minified or non-minified) JS in the first
place and everyone has a source for modification in a single place, not
spread across a dozen large packages that simply add in some JS to make
one small (but important) bit of code work.

> This whole thread is about how Debian can conform to some points of
> the DSC (e.g. points 4 and 2) by providing packages containing
> minified JS, and still conform to the DFSG, and whether that means
> some packages that are currently in main need to be moved to contrib
> or non-free.  The point of contention is not "should we package this
> software for the benefit of our users" but whether the packages are
> allowed in main, which is strictly based on whether or not they
> conform to the DFSG.

It's not about contrib or main, that is roughly equivalent to thinking
that every DFSG problem looks like a nail because all you have available
is a large hammer instead of solving the problem inside main.

It is about getting the tools to convert the source for modification
(unminified JS) which is included in packages in main which embed JS
into a minified JS that doesn't make the security problems worse by
introducing it's own bugs by not building the .min.js in the same way
as the JS upstream. It's also about implementing a method which allows
JS maintainers to keep up to date with JS upstreams so that embedding
upstreams don't have to do any of this in the first place.


Neil Williams

Attachment: pgpuGLMbuBHKv.pgp
Description: OpenPGP digital signature

Reply to: