Re: Security concerns with minified javascript code

Samuel Thibault writes: > I however agree that it seems poor practice to duplicate these build > modules in every packages. But if the required versions are different, > there is no real other way. There is another solution: put several different versions of the same

Re: Security concerns with minified javascript code

On Fri, 04 Sep 2015 17:54:30 +0200 Vincent Bernat wrote: > ❦ 4 septembre 2015 09:32 +0100, Neil Williams >  : > > [Applying patch to pre-minification source] > >> Getting the same min.js is not a goal (we don't try to get the same > >> binaries than

Re: Security concerns with minified javascript code

❦ 4 septembre 2015 09:32 +0100, Neil Williams  : [Applying patch to pre-minification source] >> This will become more difficult with jQuery 3.x (due to ES6 to ES5 >> transformation). But manual adaptation should stay straightfoward >> ("transpilation" only does local

Re: Security concerns with minified javascript code

On Thu, 03 Sep 2015 22:51:50 +0200 Vincent Bernat wrote: > ❦ 3 septembre 2015 13:19 -0700, Nikolaus Rath  : > > > 2. Many javascript packages cannot be build from source with the > > tools in main. > > This is the one I don't agree. For me,

Re: Security concerns with minified javascript code

❦ 4 septembre 2015 08:29 +0100, Neil Williams  : >> > 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

Re: Security concerns with minified javascript code

On Fri, 04 Sep 2015 10:07:13 +0200 Vincent Bernat wrote: > ❦ 4 septembre 2015 08:29 +0100, Neil Williams >  : > > > For those upstreams who have to embed JS not available in Debian, > > then the upstream code often cannot be processed in Debian, neither

Re: Security concerns with minified javascript code

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Thu, Sep 03, 2015 at 08:47:11AM +0200, Vincent Bernat wrote: > Without minification, we'll just ship packages that people won't > use. Why would I run a crippled installation of Wordpress that will > drive of part of my users to another competitor?

Re: Security concerns with minified javascript code

* Bas Wijnen [150902 17:36]: > > On Wed, 2 Sep 2015 13:33:57 -0400 Marvin Renich wrote: > > > 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

Re: Security concerns with minified javascript code

❦ 3 septembre 2015 17:22 GMT, Bas Wijnen  : > Because you know you have the right and the ability to be a part of the free > software community that created the software. That is why you are running > Debian and don't have contrib or non-free in your sources.list. > > From

Re: Security concerns with minified javascript code

* Neil Williams [150902 14:15]: > On Wed, 2 Sep 2015 13:14:31 -0400 Marvin Renich wrote: > > 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

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

Re: Security concerns with minified javascript code

* Neil Williams [150902 14:33]: > Minified isn't source for modification... [large snip] I don't believe I have disagreed with anything you said in the snipped text. I certainly did not mean to. I said that minified JS can only go in main if both the source and the tools

Re: Security concerns with minified javascript code

Paul Wise writes: > On Wed, Sep 2, 2015 at 11:47 PM, Russ Allbery wrote: >> If *no one* has access to anything better than a binary file, then >> possession of that binary file puts you on an equal footing with >> everyone else in the world, which I think is all that we can

Re: Security concerns with minified javascript code

Vincent Bernat dijo [Wed, Sep 02, 2015 at 09:47:23AM +0200]: > If you talk about uglifyjs or the like, it is already packaged and > doesn't solve all the problems we have (see my message to Odyx, > ). > > If you talk about Grunt, Grunt comes with a lot of plugins (and

Re: Security concerns with minified javascript code

On Sep 03 2015, Vincent Bernat wrote: > ❦ 3 septembre 2015 17:22 GMT, Bas Wijnen  : > >> Because you know you have the right and the ability to be a part of the free >> software community that created the software. That is why you are running >> Debian and

Re: Security concerns with minified javascript code

❦ 3 septembre 2015 13:19 -0700, Nikolaus Rath  : >>> Because you know you have the right and the ability to be a part of the free >>> software community that created the software. That is why you are running >>> Debian and don't have contrib or non-free in your sources.list.

Re: Security concerns with minified javascript code

On Wed, Sep 2, 2015 at 11:47 PM, Russ Allbery wrote: > I think reading "preferred form of modification" from the perspective of > upstream is a useful standard because it handles some edge cases like > that, and because it feels ethically consistent with free software > principles. The goal is

Re: Security concerns with minified javascript code

❦ 3 septembre 2015 12:23 +1000, Dmitry Smirnov  : >> Amazon did a study that showed every ~100ms of page load >> delay lost them 1% in sales. > > It could be that small percentage of Amazon users are impulsive trigger-happy > buyers. :) > However that conclusion is probably

Re: Security concerns with minified javascript code

On Thursday 03 September 2015 08:47:11 Vincent Bernat wrote: > Please, publish your own study. I do not need to publish any studies to be sceptical. > This number is well known and supported > by an entity which is likely to have a population large enough to be > significant. You've mentioned

Re: Security concerns with minified javascript code

❦ 3 septembre 2015 21:03 +1000, Dmitry Smirnov  : >> Without minification, we'll just ship packages that people won't >> use. Why would I run a crippled installation of Wordpress that will >> drive of part of my users to another competitor? > > Sorry but that feels like

Re: Security concerns with minified javascript code

❦ 2 septembre 2015 09:32 +0300, Lars Wirzenius  : > 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

Re: Security concerns with minified javascript code

Vincent Bernat, le Wed 02 Sep 2015 09:47:23 +0200, a écrit : > If you talk about Grunt, That's what I'm talking about. > Grunt comes with a lot of plugins (and does almost nothing without > those) and each upstream will require different plugins with different > versions (Grunt plugin versions

Re: Security concerns with minified javascript code

❦ 2 septembre 2015 09:54 +0200, Samuel Thibault  : >> If you talk about Grunt, > > That's what I'm talking about. > >> Grunt comes with a lot of plugins (and does almost nothing without >> those) and each upstream will require different plugins with different >> versions

Re: Security concerns with minified javascript code

❦ 2 septembre 2015 09:28 +0200, Samuel Thibault  : >> Healthy language communities have their own metadata systems and >> standardized build systems that allow Debian packaging to be nearly >> automated, *provided* that we use the same unit of distribution as >> upstream.

Re: Security concerns with minified javascript code

Russ Allbery, le Tue 01 Sep 2015 18:05:09 -0700, a écrit : > Healthy language communities have their own metadata systems and > standardized build systems that allow Debian packaging to be nearly > automated, *provided* that we use the same unit of distribution as > upstream. I understand that

Re: Security concerns with minified javascript code

Vincent Bernat, le Wed 02 Sep 2015 10:10:55 +0200, a écrit : > ❦ 2 septembre 2015 09:54 +0200, Samuel Thibault  : > > >> If you talk about Grunt, > > > > That's what I'm talking about. > > > >> Grunt comes with a lot of plugins (and does almost nothing without > >> those)

Re: Security concerns with minified javascript code

❦ 2 septembre 2015 10:18 +0200, Samuel Thibault  : >> Or maybe you propose to just ship the whole "node_modules" directory >> (which has all the dependencies) with jQuery sources? > > That'd be a lot better than nothing. OK. Also, node_modules for jQuery is 76M (for 3.x,

Re: Security concerns with minified javascript code

On Tue, Sep 01, 2015 at 06:05:09PM -0700, Russ Allbery wrote: > Healthy language communities have their own metadata systems and > standardized build systems that allow Debian packaging to be nearly > automated, *provided* that we use the same unit of distribution as > upstream. If we want to

Re: Security concerns with minified javascript code

* Ben Hutchings [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! I can't tell whether you are agreeing or disagreeing with me! > The

Re: Security concerns with minified javascript code

* Neil Williams [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

Re: Security concerns with minified javascript code

On Wed, 2 Sep 2015 13:33:57 -0400 Marvin Renich wrote: > * Ben Hutchings [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

Re: Security concerns with minified javascript code

On Tuesday 01 September 2015 17:46:30 Josh Triplett wrote: > Nikolaus Rath wrote: > > I don't think 28 kB vs 73 kB is a difference that people will notice > > over the network in *most* situations. Even at just 100 kB/s that's > > 0.28 vs 0.73 seconds, and only when the page is first loaded. > >

Re: Security concerns with minified javascript code

On Wed, 2 Sep 2015 13:14:31 -0400 Marvin Renich wrote: > * Neil Williams [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

Re: Security concerns with minified javascript code

The below is very much a tangent from the minified Javascript case, and not applicable to that case. Bas Wijnen writes: > 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

Re: Security concerns with minified javascript code

At Tue, 1 Sep 2015 18:56:45 +0200, Raphael Hertzog wrote: > For me, the javascripts bits in wordpress/publican are not part of the > product, they are external libraries whose preferred form of use is > by embedding a copy of the library... that sucks but it's the way it is. > > I do not see

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 wrote: > > > * Ben Hutchings [150902 10:12]: > > > My preferred form is a git repository of

Re: Security concerns with minified javascript code

Vincent Bernat debian.org> writes: > 2. Upstream may generate the final pre-minification file with complex > tools, like an AMD loader or an ES6/ES5 transpiler, along with the > use of non-packaged build tools like Grunt. > problem. For the second one, a solution would be to consider

Re: Security concerns with minified javascript code

Vincent Bernat, le Wed 02 Sep 2015 11:20:32 +0200, a écrit : > ❦ 2 septembre 2015 10:18 +0200, Samuel Thibault  : > >> Or maybe you propose to just ship the whole "node_modules" directory > >> (which has all the dependencies) with jQuery sources? > > > > That'd be a lot

Re: Security concerns with minified javascript code

* Thorsten Glaser [150902 07:50]: > There is (I just had an epiphany) another possible criterium to apply > for to determine what the preferred form of modification is: ^ for [Okay, so I'm being pedantic, but this is a common

Re: Security concerns with minified javascript code

On Wed, 2015-09-02 at 08:59 -0400, Marvin Renich wrote: > * Thorsten Glaser [150902 07:50]: > > There is (I just had an epiphany) another possible criterium to apply > > for to determine what the preferred form of modification is: >^

Re: Security concerns with minified javascript code

On Wed, 2 Sep 2015 08:59:11 -0400 Marvin Renich wrote: > * Thorsten Glaser [150902 07:50]: > > There is (I just had an epiphany) another possible criterium to > > apply for to determine what the preferred form of modification is: >

Re: Security concerns with minified javascript code

❦ 1 septembre 2015 21:10 +0200, Didier 'OdyX' Raboud  : > I think we should take a strong move there and exercise (as well as > justify to the outer world) our free software right to recompile the > software that we ship to our users: this could mean to only merge & gzip >

Re: Security concerns with minified javascript code

On Sep 01, Nikolaus Rath wrote: > I don't think 28 kB vs 73 kB is a difference that people will notice > over the network in *most* situations. Even at just 100 kB/s that's > 0.28 vs 0.73 seconds, and only when the page is first loaded. Yes, this is a non trivial difference

Re: Security concerns with minified javascript code

Vincent Bernat dijo [Fri, Aug 28, 2015 at 10:48:28AM +0200]: > >> What will happen is that maintainers will fallback to the second less > >> horrible solution and cripple the package (by using an older version of > >> the JS lib for example) to allow it to stay in main. > > > > Why would they want

Re: Security concerns with minified javascript code

Le mardi, 1 septembre 2015, 17.50:26 Vincent Bernat a écrit : > ❦ 1 septembre 2015 08:21 -0700, Nikolaus Rath : > >>> Couldn't we just use the non-minified versions in most situations? > >>> A > >> > >> Not for anything which has actual users over the network. > > > > Why?

Re: Security concerns with minified javascript code

* Raphael Hertzog [150901 12:57]: > Because we have alternative "compilers" (aka minifier) available to > recreate another minified file thas should work just as well. No. Debian does not allow you to ship a compiled C program that was compiled elsewhere; the maintainer or a

Re: Security concerns with minified javascript code

On Tue, Sep 01, 2015 at 04:42:15PM +0200, Helmut Grohne wrote: > On Tue, Sep 01, 2015 at 08:15:19AM +0200, Guido Günther wrote: > > Couldn't we just use the non-minified versions in most situations? A > > heavily loaded wordpress site might not be good example but e.g. doxygen > > documentation

Re: Security concerns with minified javascript code

Vincent Bernat dijo [Fri, Aug 28, 2015 at 11:54:43AM +0200]: > > I still find it hard to believe that *so* much code is required to > > minify JS. The excuse that JS is "moving fast" is nonsense. The reality > > would appear to be that nobody actually *cares* about the mess, they > > just use it.

Re: Security concerns with minified javascript code

❦ 1 septembre 2015 13:45 -0500, Gunnar Wolf  : >> uglifyjs is a KISS tool to minify. Unfortunately, many projects do not >> require only minification. They require transpiling (convert from ES6 to >> ES5 or from CoffeeScript/Typescript/... to vanilla JS) and dependency >>

Re: Security concerns with minified javascript code

On Tue, 01 Sep 2015, Vincent Bernat wrote: > 1. Upstream may not ship this source but only the minified version > because the JS code is just a dependency and some upstream are used > to just ship the minified source. We can recover the original code > from another source but there is a risk

Re: Security concerns with minified javascript code

Hi, On Mon, Aug 31, 2015 at 09:50:05AM +0200, Raphael Hertzog wrote: > On Mon, 31 Aug 2015, Simon Josefsson wrote: > > How would someone rebuild the minified javascript files from the > > missing-sources files? > > They would not? > > The modified non-minified files are perfectly usable even if

Re: Security concerns with minified javascript code

Josh Triplett writes: > That said, we absolutely do need to fix this in Debian: it's not OK to > build packages in main using tools not shipped in Debian, or to ship > precompiled files. As a start, it would help if when JavaScript folks > try to package the packages

Re: Security concerns with minified javascript code

On Sep 01 2015, Josh Triplett wrote: > Nikolaus Rath wrote: >> I don't think 28 kB vs 73 kB is a difference that people will notice >> over the network in *most* situations. Even at just 100 kB/s that's >> 0.28 vs 0.73 seconds, and only when the page is first loaded. > >

Re: Security concerns with minified javascript code

Nikolaus Rath wrote: > I don't think 28 kB vs 73 kB is a difference that people will notice > over the network in *most* situations. Even at just 100 kB/s that's > 0.28 vs 0.73 seconds, and only when the page is first loaded. That's absolutely a critical difference, even on a faster connection.

Re: Security concerns with minified javascript code

On Sep 01, Guido Günther wrote: > Couldn't we just use the non-minified versions in most situations? A Not for anything which has actual users over the network. > heavily loaded wordpress site might not be good example but e.g. doxygen > documentation probably doesn't suffer

Re: Security concerns with minified javascript code

❦ 31 août 2015 11:21 -0400, Marvin Renich  : >> > However, this is a readable source code that will accomodate any >> > modification that a end user will deem necessary. > > I intentionally did not look at the file referred to above, and have no > idea whether I would consider

Re: Security concerns with minified javascript code

On Sep 01 2015, Vincent Bernat wrote: > ❦ 1 septembre 2015 08:21 -0700, Nikolaus Rath  : > Couldn't we just use the non-minified versions in most situations? A >>> >>> Not for anything which has actual users over the network. >> >> Why? (Don't forget

Re: Security concerns with minified javascript code

Hi, On Mon, 31 Aug 2015, Bas Wijnen wrote: > > I certainly do not want to move wordpress or publican to contrib because > > some of the javascript libraries that it uses can't be rebuilt from main. > > In that case, my question applies to you as well: why do you care for it to be > in main, if

Re: Security concerns with minified javascript code

On Tue, Sep 01, 2015 at 08:15:19AM +0200, Guido Günther wrote: > Couldn't we just use the non-minified versions in most situations? A > heavily loaded wordpress site might not be good example but e.g. doxygen > documentation probably doesn't suffer much from non minified JS. I fail to see what

Re: Security concerns with minified javascript code

On Sep 01 2015, m...@linux.it (Marco d'Itri) wrote: > On Sep 01, Guido Günther wrote: > >> Couldn't we just use the non-minified versions in most situations? A > > Not for anything which has actual users over the network. Why? (Don't forget about gzip encoding). Best,

Re: Security concerns with minified javascript code

❦ 1 septembre 2015 08:21 -0700, Nikolaus Rath  : >>> Couldn't we just use the non-minified versions in most situations? A >> >> Not for anything which has actual users over the network. > > Why? (Don't forget about gzip encoding). See:

Re: Security concerns with minified javascript code

> On Mon, Aug 31, 2015 at 11:21:55AM -0400, Marvin Renich wrote: > > * Bas Wijnen [150830 07:53]: > > > On Sun, Aug 30, 2015 at 10:14:13AM +0200, Vincent Bernat wrote: > > > > Is that the preferred form of modification? It depends, but from the > > > > jQuery author point of

Re: Security concerns with minified javascript code

On Sep 01 2015, Helmut Grohne wrote: > On Tue, Sep 01, 2015 at 08:15:19AM +0200, Guido Günther wrote: >> Couldn't we just use the non-minified versions in most situations? A >> heavily loaded wordpress site might not be good example but e.g. doxygen >> documentation probably

Re: Security concerns with minified javascript code

On Sun, 30 Aug 2015, Bas Wijnen wrote: > Why do you care that software is in main, if you evidently do not care about > any of the rules we have for it? I don't think that implying that Vincent doesn't not care about Free Software is very constructive. Can we please stop this now? If all the

Re: Security concerns with minified javascript code

Raphael Hertzog writes: > In both cases, I worked around the problem by shipping the upstream > sources in debian/missing-sources/ but I did not support doing changes > there and did not rebuild the embedded libraries. > > In some cases, I do replace the embedded library with

Re: Security concerns with minified javascript code

On Tue, Aug 25, 2015 at 07:08:06PM +0100, Ian Jackson wrote: > Not regenerating configure doesn't pose any significant risk that > we're shipping a configure script that we can't regenerate (or, at > least, regenerate an equivalent or better one). I've not heard of > people (for example) using

Re: Security concerns with minified javascript code

On Thu, Aug 27, 2015 at 04:14:53PM -0700, Russ Allbery wrote: > 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

Re: Security concerns with minified javascript code

First, let me make it clear that I am firmly in the camp that believes minified JS cannot be distributed in main unless the tools to recreate it are also in main. It bothers me that there appears to be a not-insignificant number of people with upload rights who do not believe this. This message

Re: Security concerns with minified javascript code

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Mon, Aug 31, 2015 at 08:49:53AM +0200, Raphael Hertzog wrote: > On Sun, 30 Aug 2015, Bas Wijnen wrote: > > Why do you care that software is in main, if you evidently do not care about > > any of the rules we have for it? > > I don't think that

Re: Security concerns with minified javascript code

On Mon, 31 Aug 2015 at 16:50 Raphael Hertzog wrote: > In both cases, I worked around the problem by shipping the upstream > sources in debian/missing-sources/ but I did not support doing changes > there and did not rebuild the embedded libraries. > I haven't been paying lots

Re: Security concerns with minified javascript code

Raphael Hertzog writes: > On Mon, 31 Aug 2015, Simon Josefsson wrote: >> How would someone rebuild the minified javascript files from the >> missing-sources files? > > They would not? > > The modified non-minified files are perfectly usable even if they are a > bit larger

Re: Security concerns with minified javascript code

On Mon, 31 Aug 2015, Simon Josefsson wrote: > How would someone rebuild the minified javascript files from the > missing-sources files? They would not? The modified non-minified files are perfectly usable even if they are a bit larger than the minified ones. > The included JavaScript file is

Re: Security concerns with minified javascript code

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Sun, Aug 30, 2015 at 10:14:13AM +0200, Vincent Bernat wrote: The build script determines the outcome of what will effectively run on our users' machine. I fail to see how this is not an important issue. You are correct, this is important. But

Re: Security concerns with minified javascript code

❦ 29 août 2015 19:12 -0700, Steve Langasek vor...@debian.org : Yet you try to compare this with autoconf. Even if we tolerated configure scripts today in the archive that we can't rebuild using the software in Debian (which by and large we do *not* tolerate - because we've learned our

Re: Security concerns with minified javascript code

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Sun, Aug 30, 2015 at 02:12:43PM +0200, Vincent Bernat wrote: This is becoming quite a stretch. At this rate, we will fail to match SC#2 because we ship previous versions of software and upstream is unlikely to accept a patch against a

Re: Security concerns with minified javascript code

On Sun, Aug 30, 2015 at 10:14 AM, Vincent Bernat wrote: The build script determines the outcome of what will effectively run on our users' machine. I fail to see how this is not an important issue. But until the effort to get ppc64el, not regenerating the configure script was just a fine

Re: Security concerns with minified javascript code

On 08/28/2015 01:14 AM, Russ Allbery wrote: Bas Wijnen wij...@debian.org writes: 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

Re: Security concerns with minified javascript code

❦ 30 août 2015 11:52 GMT, Bas Wijnen wij...@debian.org : However, this is a readable source code that will accomodate any modification that a end user will deem necessary. That is not the only reason that we want the user to have source. They are not some detached customer. When we make

Re: Pacakging small package (was Re: Security concerns with minified javascript code)

Bastien ROUCARIÈS, le Sun 30 Aug 2015 23:15:39 +0200, a écrit : What could be done in order to improve the whole system performance in order to package really small package ? Is it not possible to group them like X.org does? Samuel

Re: Security concerns with minified javascript code

Steve Langasek vor...@debian.org writes: […] Nevertheless, for packages that *are* in Debian, we should expect that the source package contains the *full* corresponding source code for any minified javascript files. If we can't rebuild it then we don't actually have the source, and that's a

Re: Security concerns with minified javascript code

]] Vincent Bernat 1. package the whole Grunt ecosystem (and maintain it), 2. cripple their package by substituting some components by a non-working version in Debian or, 3. ship a pre-compiled/minified version of the library with sources. I know this sucks, but if I have to pick my

Re: Security concerns with minified javascript code

On Fri, Aug 28, 2015 at 07:42:42AM +0200, Vincent Bernat wrote: The main effect of this religious and overzealous application of our guidelines is that people just stay away of JS stuff in Debian and packaging any web-related app is becoming more complex as anyone needs to deal with JS

Re: Security concerns with minified javascript code

Vincent Bernat ber...@debian.org writes: 28 août 2015 01:46 GMT, Bas Wijnen wij...@debian.org : 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,

Re: Security concerns with minified javascript code

❦ 28 août 2015 10:29 +0200, Samuel Thibault sthiba...@debian.org : What will happen is that maintainers will fallback to the second less horrible solution and cripple the package (by using an older version of the JS lib for example) to allow it to stay in main. Why would they want to stay

Re: Security concerns with minified javascript code

On Fri, 28 Aug 2015 10:45:16 +0200 Samuel Thibault sthiba...@debian.org wrote: Vincent Bernat, le Fri 28 Aug 2015 10:06:17 +0200, a écrit : Maybe it can be trimmed a bit more, but that's still 239 unique dependencies. Note that you don't have to make that 239 debian packages, you could

Re: Security concerns with minified javascript code

On Monday 24 August 2015 13:54:21 Simon Josefsson wrote: I believe the blog post below has relevance to Debian's stance on including minified JavaScript in packages: https://zyan.scripts.mit.edu/blog/backdooring-js/ Thank you for a nice argument against minification. During packaging I

Re: Security concerns with minified javascript code

Neil Williams, le Fri 28 Aug 2015 10:32:52 +0100, a écrit : On Fri, 28 Aug 2015 10:45:16 +0200 Samuel Thibault sthiba...@debian.org wrote: Vincent Bernat, le Fri 28 Aug 2015 10:06:17 +0200, a écrit : Maybe it can be trimmed a bit more, but that's still 239 unique dependencies.

Re: Security concerns with minified javascript code

❦ 28 août 2015 10:32 +0100, Neil Williams codeh...@debian.org : I still find it hard to believe that *so* much code is required to minify JS. The excuse that JS is moving fast is nonsense. The reality would appear to be that nobody actually *cares* about the mess, they just use it. It's a

Re: Security concerns with minified javascript code

❦ 28 août 2015 12:03 +0200, Samuel Thibault sthiba...@debian.org : I wonder why mere gzip compression is not used. Don't all browsers support Accept-Compress: gzip? Minification saves some additional bytes. About 10% (when gzipped). -- If you tell the truth you don't have to remember

Re: Security concerns with minified javascript code

Vincent Bernat, le Fri 28 Aug 2015 10:06:17 +0200, a écrit : Maybe it can be trimmed a bit more, but that's still 239 unique dependencies. Note that you don't have to make that 239 debian packages, you could as well just ship them all in one package, as long as the whole code passes NEW, i.e.

Re: Security concerns with minified javascript code

Vincent Bernat, le Fri 28 Aug 2015 10:48:28 +0200, a écrit : ❦ 28 août 2015 10:29 +0200, Samuel Thibault sthiba...@debian.org : What will happen is that maintainers will fallback to the second less horrible solution and cripple the package (by using an older version of the JS lib for

Re: Security concerns with minified javascript code

Dmitry Smirnov only...@debian.org writes: On Monday 24 August 2015 13:54:21 Simon Josefsson wrote: I believe the blog post below has relevance to Debian's stance on including minified JavaScript in packages: https://zyan.scripts.mit.edu/blog/backdooring-js/ Thank you for a nice argument

Re: Security concerns with minified javascript code

❦ 28 août 2015 08:22 +0100, Philip Hands p...@hands.com : 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

Re: Security concerns with minified javascript code

Vincent Bernat, le Fri 28 Aug 2015 07:42:42 +0200, a écrit : Yes, that is a danger. I think putting those things in contrib should be a good solution if rebuilding is such a big problem. Because if it is, the code really really doesn't belong in main. What will happen is that

Re: Security concerns with minified javascript code

Vincent Bernat wrote: (...) It has already been said numerous time in the past, for some Javascript code, we don't really have the tools in Debian to easily go from the source to the minified version. It's possible, but without the appropriate tools, it's painful. I've been using

building jquery without grunt (was Security concerns with minified javascript code)

On Fri, Aug 28, 2015 at 10:06:17AM +0200, Vincent Bernat wrote: ❦ 28 août 2015 08:22 +0100, Philip Hands p...@hands.com : 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

Re: Security concerns with minified javascript code

Russ Allbery wrote: Neil Williams codeh...@debian.org writes: Usable software needs usable tools. The problem is that this *is* usable for nearly all the people who currently use it, who just run one command to install it and have all those dependencies pulled from a remote repo for them.

Re: Security concerns with minified javascript code

On Fri, Aug 28, 2015 at 4:12 PM, Jean-Michel Vourgère nir...@debian.org wrote: Vincent Bernat wrote: (...) It has already been said numerous time in the past, for some Javascript code, we don't really have the tools in Debian to easily go from the source to the minified version. It's

Re: Security concerns with minified javascript code

Neil Williams codeh...@debian.org writes: I still find it hard to believe that *so* much code is required to minify JS. The excuse that JS is moving fast is nonsense. The reality would appear to be that nobody actually *cares* about the mess, they just use it. This is almost certainly

Re: Security concerns with minified javascript code

On Fri, Aug 28, 2015 at 4:12 PM, Jean-Michel Vourgère nir...@debian.org wrote: Vincent Bernat wrote: (...) It has already been said numerous time in the past, for some Javascript code, we don't really have the tools in Debian to easily go from the source to the minified version. It's

  1   2   >