Re: Security concerns with minified javascript code

[Lars Wirzenius <liw@liw.fi>]

On Tue, Sep 01, 2015 at 06:05:09PM -0700, Russ Allbery wrote:
> Healthy language communities have their own metadata systems and
> standardized build systems that allow Debian packaging to be nearly
> automated, *provided* that we use the same unit of distribution as
> upstream.  If we want to make any headway on the huge Javascript
> ecosystem, we can't rely on individuals hand-packaging each one of those
> libraries.  We need to be able to use tools to do nearly all the packaging
> work automatically and ask humans only to do sanity checking and bug
> triage and the other parts of the work that we can't automate.  And that's
> way harder if they also have to fight with rebundling upstream releases
> into some other format.

I fully agree with this. Thank you, Russ, for expressing it clearly.

However, I want to raise the point that upstreams do not always make
sensible decisions, and if they don't, it's good to raise that with
them. For example, there was recently an ITP bug for
node-number-is-nan. Upstream source code is at
https://github.com/sindresorhus/number-is-nan, and the whole package
boils down to these four lines of code:

    'use strict';
    module.exports = Number.isNaN || function (x) {
            return x !== x;
    };

(https://github.com/sindresorhus/number-is-nan/blob/master/index.js)

If something or someone needs this, we should package it, and it seems
Grunt needs it. However, it doesn't seem sensible to have a package
for every one-liner Javascript function, either in Debian or upstream.
That's going to be a lot of packages, and that alone makes things
harder to manage for everyone. It'd make sense for the Javascript
community to produce a more general library to make ES5 look more like
ES6, which would include a number of such functions.

-- 
Schrödinger's backup hypothesis: the condition of any backup is
undefined until a restore is attempted. -- andrewsh