[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:14:31 -0400
Marvin Renich <mrvn@renich.org> wrote:

> * Neil Williams <codehelp@debian.org> [150902 10:22]:
> > Upstream is another recipient of code distributed under copyleft.
> > Having changes in a format which upstream can use is absolutely a
> > sensible and sane criterion for what is regarded as the form of the
> > code for modification. To do otherwise is to make the maintenance
> > burden untenable.
> > 
> > Every recipient needs to get the source code and the maintainer
> > changes in a format which is suitable for modification and that
> > includes the work of modification required to incorporate those
> > changes into the next upstream release. To rule out upstream
> > requirements is nonsense.
> The whole point of this discussion is what does Debian require of
> upstream for upstream to get its software distributed in Debian main.
> It is presumed that upstream already has what it considers "source";
> in the case of this thread, that is minified JS.

Actually, not. Source, for upstream of JQuery at least, is a set of
directives to include files into a non-minified jquery.js which is then
minified as part of the build in Debian. At that point, we're all good.
It's when other packages have to have other bits of jquery which aren't
packaged or are out of date in Debian and end up pulling those in
as .min.js - there needs to be a way of still using those whilst
allowing for fixes to be applied and used. That is what we lack - the
ability to rebuild embedded .min.js from *any* source for modification.
The problem is that the further that tool diverges from the variety of
tools used by the variety of JS upstreams, the more likely it is that
Debian will introduce further bugs into the .min.js which the JS
upstream will not be able to reproduce.

There are three players:

0: Debian - needs to fix problems in JS wherever we find them.

1: The JS upstream and their non-packaged minifier - may be unaware of
the problem and have their own "source for modification" format. There
may be a maintainer in Debian, likely there is not or the package is
too far out of date. (JS upstreams where the code is up to date must be
dealt with by symlinks into the packages using that JS.)

2: The embedding upstream who use the .min.js but need a way of
patching actual source JS and rebuilding a new .min.js which is,
hopefully, as close to the old one + that one fix as possible without
introducing further bugs.

If there's no embedding upstream, the JS doesn't matter to Debian - we
aren't likely to find bugs in unused libraries of any language, except
FTBFS and someone will probably file an RM RoQA.

If the embedding upstream is writing JS of their own, then they need a
minifier in Debian main too.

None of those players are using or can use the minified JS as source or
for any form of modification other than rebuilding. The current players
are using *different* formats for modification and all lack
packaged or consistent tools to get from one to another.

It is a complete mess - with the embedding upstreams lost in the middle
with no idea of what they can do to avoid getting in the way.

> My point is that if what upstream considers to be "source" is not
> acceptable to Debian, and the Debian packager has to grab real source
> from other places and use a build process that is different from what
> upstream uses in order to make the Debian package satisfy the DFSG,
> then upstream's wishes are not relevant to whether the Debian package
> conforms to the DFSG.

There are different upstreams here. The upstream of the package
embedding the minified JS, yes, that situation needs a fix. The
upstream of the original JS that went into the minified JS has a
different source for modification again - and that one is likely to be
one of the ones which needs a whole gamut of packages to run the
minifier that actually produces the embedded .min.js.

No JS or embedding upstream is going to work with the .min.js as
modifiable source. That's clearly nonsense. What is happening is that
upstreams who need to embed JS are not finding the packages available
and therefore embed and then reference that file in that upstream
as .min.js.

The solution is to have a way of rebuilding that .min.js in Debian so
that fixes can be applied to the available JS for that file - and yet
the upstream for that JS file is likely to have a different build
process from that, so we end up with three possible source formats for
modification - JS upstream, embedded unminified and the one nobody can
actually modify but the one everyone wants to rebuild: minified.

> Furthermore, if the Debian packager does not like upstream's
> arrangement of source, even if it would satisfy the DFSG, and wishes
> to rearrange it, whether or not the packager's arrangement satisfies
> the DFSG's meaning of source should be judged on its own merit, not
> on whether upstream is willing to accept patches based on the Debian
> packager's arrangement.

It's up to the maintainer to handle upstreaming of changes but it is a
lot easier if maintainer and upstream agree. An embedding upstream are
happy to get the unminified JS - provided the .min can be built. The JS
upstream, likely as not, have a different format and a different
minifier, so unminified JS used by the embedding upstream isn't going
to be relevant.

Right now, embedding upstreams are in a tangle. There's no clear way to
rebuild the .min.js and the "source" is not necessarily what the
original upstream actually edits.

> I am _not_ saying this this is necessarily a good decision.  The
> distinction is between the DFSG, which is one part of the Debian
> Social Contract, and the whole DSC.  DSC point 2 requires that the
> Debian maintainer give back to upstream.  But that has nothing to do
> with what satisfies the DSFG definition of source.

In practical terms it does, because the maintainer is not going to look
after two different formats without a tool to convert to and fro. Most
JS upstream build tools don't go in reverse, so the released source
used by the embedding upstream is not useful to the JS upstream.

The harder it is to introduce or update JS which isn't yet packaged or
is already out of date, the worse this problem will become.

> My argument is not that Debian should not use a form that upstream
> likes, but that the definition of "source" for purposes of the DFSG is
> independent of upstream's definition of source.  If both source forms
> A and B satisfy the DFSG, and upstream uses form A, that does not make
> form B fail to satisfy the DFSG, even for Debian packages of
> upstream's software.

Somewhere in the chain, the original upstream for the JS embedded into
some other package will benefit from having changes from Debian made
available in a format which can be integrated into that upstream.

The other upstream, the one embedding the .min.js, will also benefit
because then a new .min.js will be available from upstream containing
fixes from other distros as well as Debian, maybe.

Debian benefits if the JS upstream is simple to introduce and maintain
in Debian because embedding upstreams can remove the embedded copy and
symlink to the JS we all want to use - properly maintained, packaged JS
built and minified with tools in main.

If we forget about or disregard getting the security fixes from Debian
into JS upstreams and concentrate only on the embedding upstreams, we
will go backwards.


Neil Williams

Attachment: pgpo1UIwpgivG.pgp
Description: OpenPGP digital signature

Reply to: