Re: Security concerns with minified javascript code
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Wed, Sep 02, 2015 at 07:33:10PM +0100, Neil Williams wrote:
> On Wed, 2 Sep 2015 13:33:57 -0400
> Marvin Renich <mrvn@renich.org> wrote:
>
> > * Ben Hutchings <ben@decadent.org.uk> [150902 10:12]:
> > > My preferred form is a git repository of code written in C, Python,
> > > or some other language I know. That doesn't mean that a tarball of
> > > Haskell code is non-free!
>
> > No, "A preferred form" is what upstream uses. The DFSG does not use
> > the term "THE preferred form", and I believe that was wise.
The DFSG doesn't define source at all. There seems to be consensus (you're the
only one who doesn't seem to agree) that the definition from the GPL is a good
one, and that does say "the".
> > There can be multiple "preferred forms" for some software, and all are, in
> > my opinion, acceptable by the DFSG. The real question is whether it is
> > reasonable to expect someone who wishes to modify the software to consider
> > the form "source".
I disagree partly. It is possible to copy a generated file and use that as
source. IMO that isn't the case until there have actually been made
modifications to that file, though. If an upstream (which doesn't need to be
the original upstream) actually uses a file to make modifications, an argument
can be made that this format is source.
At the same time, we should try to convince upstreams that do such a thing to
stop it; it causes code duplication and a (security) support nightmare.
"Someone might think they can make modifications to this file" is much too
broad; for some modifications a hex editor is good enough. And in some cases
that is totally reasonable, such as an executable for which you don't have
source. That doesn't make binary exectutables source.
A requirement that there is a (serious, not set up to circumvent this rule)
upstream that actually uses this format as their source is still too broad, but
it's a lot better than the overly broad definition you propose. With your
definition, literally everything is source.
Here's a rule to limit the selection a bit: a file is certainly not source if
it was originally generated from a different file, and has not been modified.
> Minified isn't source for modification, that much is as far as we've
> got on consensus in this thread. However, lintian has had checks on
> minified without unminified JS available for some time and embedding
> upstreams can follow that, so there is source for modification which
> the embedding upstream would be able to use but, likely as not, the
> original JS upstream would not.
If the embedding upstream wants to use updates from the original upstream, they
will not want to make changes to the generated code. By the sound of it they
haven't figured that out yet, but if they port their changes to new releases of
the original upstream, then those releases are definitely not source,
regardless of whether the embedding upstream is using them for modification.
> Debian could mandate that embedding upstreams do not include .min.js at
> all and I could live with that. It doesn't fix the problem that Debian
> lacks a sane way of maintainers keeping javascript packages up to date
> with javascript upstreams in ways that embedding upstreams can actually
> use.
Why? If we rebuild everything, the embedding upstreams can copy our build
procedure, or they can take the minified file we generated.
> The result of that is making software in Debian worse by having more
> unminified embedded copies at different versions across lots of
> packages, exponentially more security issues and more JS packages out of
> date relative to the JS upstream. That would not be good.
I thought the minified files were going to be in their own package so there can
be symlinks? Any other solution involves code duplication which causes those
problems.
> Embedding software is a bad idea - Debian needs a way of keeping
> javascript packages up to date with JS upstreams so that other
> upstreams don't need to embed (minified or non-minified) JS in the first
> place and everyone has a source for modification in a single place, not
> spread across a dozen large packages that simply add in some JS to make
> one small (but important) bit of code work.
Upstreams will always continue embedding though, because even if Debian fixes
it, not everyone will. And they want their software to run on those other
platforms as well. So what we want, is to make sure that Debian doesn't need
the embedded copy. It can still be there, we just shouldn't use it.
> It's not about contrib or main, that is roughly equivalent to thinking
> that every DFSG problem looks like a nail because all you have available
> is a large hammer instead of solving the problem inside main.
But in the end, it is. If a maintainer refuses to make their package conform
to the DFSG, it cannot be in main. We all agree that fixing the problem is
better, but people are now claiming that literally every file is source, and
previously claimed that as long as the source is available, there's no problem
if the compiler to turn it into the embedded compiled version is not in main.
The first statement is something they can try to defend, because we don't have
a definition of source. I'm pretty sure that if we would escalate it to the TC
or a GR (no, I'm not suggesting either of those is a good idea), everyone else
agrees that this definition is wrong.
The second statement is indefensible; we have a written document (policy) which
clearly states that free software that requires software that is not in main to
build belongs in contrib. If we agree that the compiler is not in main, I
don't see how they can continue to claim that this software can be in main.
> It is about getting the tools to convert the source for modification
> (unminified JS) which is included in packages in main which embed JS
> into a minified JS that doesn't make the security problems worse by
> introducing it's own bugs by not building the .min.js in the same way
> as the JS upstream. It's also about implementing a method which allows
> JS maintainers to keep up to date with JS upstreams so that embedding
> upstreams don't have to do any of this in the first place.
That would be the proper solution. It seems to me though, that some
maintainers aren't particularly interested in making this happen, because they
don't seem to agree that there is a problem.
Thanks,
Bas
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQIcBAEBAgAGBQJV52upAAoJEJzRfVgHwHE6WfcP/2e1zsXJOhuZomYPDVHGKApu
lLcUdTlpOhrg5W+FU/pUg0y+hA2bucJhQ8i83VaYY5Bh1YQCxwV/kU129IULym5l
w5bQQDOlwSS6rUi9kmI+VO2aPV2uH12bguQMzjxcDDOr5uVLlClXh6+JX2k/5BMc
sDELNasfXG7yHoUmlBkCrjZkj3aSaDVthkeTD3nq1mdoyKkDQwb06Or9GW4z5u7G
gTt/wAEjC525rLZPd/0U1w7ew+v+g5Lz4k0sXD6jlViDHxwZY2QeMeflvuS6pvdb
/90KjJh8Gw3G5Ou2N2UL6bPYgIooyVGl/E5KT89Yic75Yn5ZNQOQFtMsNZruGyNh
+P+Ghwy8QsunCnTpNUnqXbiwABN4+xW2C6hZfVbSMuxo89dul8IRwkMOHFTngOl/
Nx2saPUDHVyWosvl/DXBMKlIZgHQOYsdRVp6+TC7xiRVI998PO25KkqSRCCCIcuV
zNFrTj5iJpsriwVz0lbx0nvIGX3HMBvQn0Ua2JMnlRUSJpz/VFU8CQQ6HB+8P03S
DGLwX1kmIr3FP80OlueDjgR2sTkZeYwP9i5xDb3g2sn0TfRvRu63IMs6KbO1LG02
MQjAIEZPaYObefvjdQl83mai6HN/sRQFrgqsLzcczfnGcuxqLy/tdvO+TtDIFpwn
SOLQnKGZnih9jE6yXzMZ
=4E1N
-----END PGP SIGNATURE-----
Reply to: