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

Re: Security concerns with minified javascript code



-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Thu, Aug 27, 2015 at 04:14:53PM -0700, Russ Allbery wrote:
> Bas Wijnen <wijnen@debian.org> writes:
> 
> > On the other hand, shipping packages that cannot be rebuilt with tools
> > from Debian will also result in angry users.  For me personally, one of
> > the bigger reasons I use Debian is that we take good care that I can
> > modify everything on my system, and use the modified version.  The users
> > you're talking about probably don't care (much) about this, and should
> > have contrib and non-free enabled.
> 
> > Why should code that doesn't meet our standards (compiler in main) be
> > allowed in main?  What is the downside of putting it in contrib?  "Users
> > who don't have contrib enabled can't use it then" is a feature, not a
> > bug.
> 
> Last time I checked, Doxygen includes minified Javascript in all of its
> generated output.  Would we have to move every piece of Doxygen-generated
> documentation into a separate package so that we could put it in contrib,
> or strip it from our packages?

These are not the only solutions.  We have many bugs in our packages that we
would like to fix, but that doesn't mean they're all fixed.  As long as we are
working on the issue, we can live with it.  But I get the feeling that people
just want to let it be this way and never fix it.  That is not a solution IMO.

And yes, I think this is important.  I think files that cannot be regenerated
with programs from main do not belong in main.  It surprises me that this is
controversial, really.

I'll agree that in this case it is something that may be accepted for a while,
but not that it doesn't require fixing.

But I still don't understand the problem.  Originally I thought minifying
consisted of renaming identifiers to be short and removing whitespace.  That
can be omitted at almost no cost.  I just learned that files may be combined.
That can be done with cat.  Even if the minifying tools that upstream use
constantly change and aren't suitable to be packaged, what complex thing do
they do that can't be done with commandline tools?  Why can't we fix this
problem by just minifying our own way, which may be less cool, but just as
effective?

Or alternatively, by packaging the minifier that is being used with the package
that needs it.  Yes, that's a horrible idea with lots of code duplication, but
if I understand the problem, every JS file must be minified with the exact
version of the minifier that upstream used, so then every package would have
its own unique package that it depends on, and in that case they can just be
merged.  But it can't really be that bad, right?

> This is typical of the sorts of problems that I would expect.  It would
> surprise me if this were a smaller project than the GFDL purging.  It
> might be quite a bit larger.

If the minifiers are so complex and at the same time unpackageable, I think it
is the right thing to do, though.  Our main+contrib+non-free users won't care
(and they won't notice either), but our main-only users expect it of us.  It is
very similar to the GFDL situation, indeed.  Including the fact that there
seems to be discussion about whether there is a problem.

But let me be clear: I don't maintain any minified JS code.  I don't expect to
be doing this work.  I'm also not saying that other people must do it right
away.  I am saying that they should consider this a serious issue, because it
breaks our promise to the community.  So even though it doesn't have to be
their top priority, I certainly hope it is something that they think of as a
bug, which deserves to be fixed at some point.  From this discussion it seems
there is no consensus on that, and that worries me.

Thanks,
Bas
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQIcBAEBAgAGBQJV372GAAoJEJzRfVgHwHE6C2AP/0C8I1yg3QiEoeYNyRWJzQpx
c9BzlB2ISimbym2DjAMVf0hZSzjFTY2q5BNMt8vmqOeKJ/TxlkwzxXC+ZSoLo+2o
E69gQvLrFpnLdO+z+8YZdoLPpz9S3l6HkhlUVVVlRiqdPSL3Pb3vI8w7nSBEpfqE
ooavdNvug10O6w0SiY3EhTeTVzmCF4pi/ZCyU4n8fmDHJT3xRG+SgrYe1YYq3QkR
qESTLXaoBVu4B7tcWUAJvbC0ICG7n0K3JD2t1fcM1WmiBZYWwuNmBSt9yDeYmeq9
OKGWAYvWRK55/9ofRvMgAk3yA0eqm4+XQw4DFixFUidCHHLrUAN91nJGsjjkin3O
JanPvbrk+pg4MWZSol9UESp0iLTawahEedYWjD8Jdckhb8fWul3c2SOms/2zhCJS
fb58BpdKihB4n4UzrDpB1O6MNF/66JV+0Iji4mspH3HsZuB93yYEtgV1JntmLP3r
eZKUJt7tjlydzNfJc/mb0AoyHfUip8pakexDb/AnQzqP2q17lLitoTRsp8Q4kgJM
1Vmm9AGJm+1ki5jwHtrQSOj0VRtxZdbmRFgUkr1yRdMis5iI+DVUPlOk6wq5cjbQ
Y0yo8eFx3rk2gXrQaIyQ33/Ntc7NgLy3W1fjgaV+W2H9AxSRqTkqB/f6hxys2qaF
+1wo0YDVgi4tef9wbheP
=LJbz
-----END PGP SIGNATURE-----


Reply to: