On Thu, 03 Sep 2015 22:51:50 +0200 Vincent Bernat <bernat@debian.org> wrote: > ❦ 3 septembre 2015 13:19 -0700, Nikolaus Rath <Nikolaus@rath.org> : > > > 2. Many javascript packages cannot be build from source with the > > tools in main. > > This is the one I don't agree. For me, pre-minification source is > source code. If you show the pre-minification version of jQuery, many > people will believe this is a valid source code (original comments, > variable names and indentation are here). ... except that what you are referring to there is the "source" as it appears as an unminified JS file on the filesystem after the upstream code is packaged by Debian. The JQuery upstream is a set of directives to include other snippet files which are then further processed into both the unminified JS that looks like source code and the minified JS which tends to get used by applications. The "source code" that everyone talks about is actually not edited by anyone, least of all upstream, it not used by applications (which embed the .min.js) and it is not convertible to the source for modification used by JQuery upstream, so patches to that are of no use to fixing security bugs in JQuery as packaged in Debian. JQuery in Debian *does* build from upstream source using only tools available in Debian main. What it builds from is not usable to applications, but if a bug is reported in the minified or unminified JS, the maintainer (together with the JQuery upstream) can prepare a patch to the source code that is built in Debian to produce a change in the minified and unminified *generated files* for other applications to use. Patching an unminified JS file as it exists on the filesystem from packaging doesn't actually help anyone, except possibly in debugging the security hole. Even then, one of the more serious problems with minification is that it isn't just a process of removing comments and whitespace, the minifier can inject bugs which are not present in the unminified version. Using a different minifier can introduce *different* *unknown* bugs that only affect the version patched to "improve security". We really need to think of minifiers as transformational - these are compilers in many ways. For those upstreams who have to embed JS not available in Debian, then the upstream code often cannot be processed in Debian, neither can the unminified JS be minified into the same .min.js file as embedded due to a lack of tools in Debian. In that sense, the current lintian requirements are a hindrance and a mess because they require the embedding upstream to include "source code" which cannot be converted to the actual running code using tools in main in a reproducible manner. Using a different minifier results in an untested and unverifiable .min.js with no assurance that new bugs have not been introduced. This thread isn't principally about how JS packages already in main actually get built and patched, this is about how upstreams who need to embed JS not available in Debian can support security fixes to javascript. Patches which produce a third form of the code which produces a diff to the buggy version that is massively larger than the security fix itself will not find favour with the release team or security team during a release freeze. The maintainers and upstreams of such packages *need* Debian to come up with an answer for how their code needs to handle security fixes within Debian. A way that produces a minimal diff to the released version to make it practical to review the change to a package already in stable. A way that absolutely does NOT introduce new bugs. A way that is exclusively possible using tools available in Debian main. Can we *please* talk about that now? Please don't leave this until the release freeze for Stretch is on the horizon. This thread has gone on for ages with bike-shedding, tippy-toeing around DFSG sidelines and insane ideas about non-free but with no useful output for those who are actually trying to fix the *SECURITY PROBLEM*. There is a fundamental misconception in a lot of these discussions which drops embedding upstreams right in the toilet. There is a real problem here and it has nothing to do with whether packages go into contrib or non-free. It is whether packages embedding javascript can have sane security support in any part of Debian. Moving stuff to non-free is *not* a security fix! The core problem is *not* about legality or "preferred source for modification" or the DFSG or a move to contrib/non-free - those are (large) complicating factors. The core problem is how to fix undiscovered security holes in packages already in Debian stable which need to embed JS not available in Debian. This is a technical and packaging problem, not a licence or legal one. We're taking about the *security* of free software, not whether it is free or not. > > 3. Software that cannot be build from source with the tools in main > > must not go in main but into contrib > > I agree. And doing from pre-minification source to minified source is > possible with the tools in main (uglifyjs or yui-compressor). Not in a way that reproduces the same .min.js as the original source - unless that is from a package already in Debian and the same minifier is used (with the same options). Unless we solve the problem of being able to apply security fixes, the location of the package within the archive is completely irrelevant. -- Neil Williams ============= http://www.linux.codehelp.co.uk/
Attachment:
pgpVTcTOmb6JK.pgp
Description: OpenPGP digital signature