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

Re: Security concerns with minified javascript code

Lars Wirzenius dijo [Wed, Sep 02, 2015 at 09:32:12AM +0300]:
> 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.
> (...)

I agree, having all the boilerplate and infrastructure that make up a
package makes very little sense in this case. We have several packages
that are made up of bits from different origin, but linked with a
common target. The first example that comes to my mind is devscripts
(which, yes, has important peculiarities, such as being mostly written
by Debian-people as upstreams), but others can be mentioned
(i.e. emacs-goodies, texlive-generic-extra, etc.)

Such a package could be created for all such Javascript snippets which
present a ES6→ES5 "transpiler" (I still don't believe in such a term),
i.e. things such as what's mentioned at:



That is, one package that would allow using tricks such as Perl
(>=5.10)'s "use feature" and "no feture" tricks that allow for Perl6

Reply to: