Re: Security concerns with minified javascript code

[Gunnar Wolf <gwolf@gwolf.org>]

Vincent Bernat dijo [Fri, Aug 28, 2015 at 11:54:43AM +0200]:
> > I still find it hard to believe that *so* much code is required to
> > minify JS. The excuse that JS is "moving fast" is nonsense. The reality
> > would appear to be that nobody actually *cares* about the mess, they
> > just use it.
> 
> It's a feature. The JS community is quite proud to have so many packages
> for so little tiny tasks. Their packaging system enables to do this
> "easily".

Sounds much like the canonical description of Unix, only throwing
aside tens of years of engineering best practices.

> > Why isn't there a KISS tool to do this? Is it all just special
> > snowflake optimisations for what has to be / should be a simple process
> > of removing whitespace and collapsing the formatting?
> 
> uglifyjs is a KISS tool to minify. Unfortunately, many projects do not
> require only minification. They require transpiling (convert from ES6 to
> ES5 or from CoffeeScript/Typescript/... to vanilla JS) and dependency
> handling (through loaders). And this is becoming more and more common
> because people want to use ES6 or some more modern JS.

...If so, they should be properly labeled and treated as something
different. "Transpiling" effectively means "compiling", and we know
what requirements we have with code in order to accept it compiled: We
need to have the sources as well. Nobody will argue that we don't have
to ship sources for binaries on ARM platforms because ARM has enough
registers so that compiled objects are as good as source.

And, of course, having a tool behave as a compiler when it does not
really understand the mess it is creating... Well, leads to gaping
holes such as what Yan describes here:

    https://zyan.scripts.mit.edu/blog/backdooring-js/

A beautiful way of showing how minification hurts.