Security concerns with minified javascript code

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/ To me the problem suggests that it is important from a security and accountability perspective to 1) include the human-readable source cod

Re: Security concerns with minified javascript code

On 08/24/2015 01:54 PM, 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/ > > To me the problem suggests that it is important from a security and > accountab

Re: Security concerns with minified javascript code

* Thomas Goirand , 2015-08-24, 16:08: 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/ To me the problem suggests that it is important from a security and accountability perspective t

Re: Security concerns with minified javascript code

On Tue, Aug 25, 2015, at 11:04, Jakub Wilk wrote: > Do we actually require re-minifying JS code at build time? You can either ship the unminifyied JS, or minify it at build time. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them.

Re: Security concerns with minified javascript code

Quoting Jakub Wilk (2015-08-25 16:04:52) > * Thomas Goirand , 2015-08-24, 16:08: >>>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/ >>> >>>To me the problem suggests that it is

Re: Security concerns with minified javascript code

❦ 25 août 2015 16:04 +0200, Jakub Wilk  : >>> 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/ >>> >>> To me the problem suggests that it is important from a security and >>> a

Re: Security concerns with minified javascript code

On Tuesday, August 25, 2015 05:12:56 PM Vincent Bernat wrote: > ❦ 25 août 2015 16:04 +0200, Jakub Wilk : > >>> 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/ > >>> > >>

Re: Security concerns with minified javascript code

Quoting Scott Kitterman (2015-08-25 17:57:11) > On Tuesday, August 25, 2015 05:12:56 PM Vincent Bernat wrote: >> ❦ 25 août 2015 16:04 +0200, Jakub Wilk : > I believe the blog post below has relevance to Debian's stance on > > including minified JavaScript in packages: >https://zya

Re: Security concerns with minified javascript code

Jakub Wilk dijo [Tue, Aug 25, 2015 at 04:04:52PM +0200]: > >>To me the problem suggests that it is important from a security and > >>accountability perspective to 1) include the human-readable source code > >>of JavaScript in Debian packages, and 2) to compile the human-readable > >>source code int

Re: Security concerns with minified javascript code

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Tue, Aug 25, 2015 at 07:17:12PM +0200, Jonas Smedegaard wrote: > Quoting Scott Kitterman (2015-08-25 17:57:11) > > AFAIK we've only ever discussed the need to provide source. I don't > > know why there would be a requirement to reminify. > > I se

Re: Security concerns with minified javascript code

Scott Kitterman dijo [Tue, Aug 25, 2015 at 11:57:11AM -0400]: > > No, we don't require to rebuild everything from source. It should just > > be possible to do it with what is in main. The last occurrence that I > > can find of this discussion is here: > > https://lists.debian.org/debian-devel/2014

Re: Security concerns with minified javascript code

Bas Wijnen writes ("Re: Security concerns with minified javascript code"): > AFAIK Debian doesn't *require* generated files to be rebuilt. For > example, it used to be common practice for a long time to copy > config.{guess,sub} from autotools-dev instead of regenerating t

Re: Security concerns with minified javascript code

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Tue, Aug 25, 2015 at 07:08:06PM +0100, Ian Jackson wrote: > Bas Wijnen writes ("Re: Security concerns with minified javascript code"): > > AFAIK Debian doesn't *require* generated files to be rebuilt. For > > example,

Re: Security concerns with minified javascript code

* Ian Jackson , 2015-08-25, 19:08: 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). Autotools stuff tends to bitrot, just like everything else. There's a reason

Re: Security concerns with minified javascript code

Jakub Wilk writes ("Re: Security concerns with minified javascript code"): > Ian Jackson , 2015-08-25, 19:08: > >I've not heard of people (for example) using private autoconf macros > >not included in their build tree. > > #580190 *reads* *blink* Err,

Re: Security concerns with minified javascript code

❦ 25 août 2015 17:58 GMT, Bas Wijnen  : > I don't see why javascript minification would be different from C compilation > in a way that would lead to a different way of handling it. Playing a bit of devil's advocate here, but... It has already been said numerous time in the past, for some Javas

Re: Security concerns with minified javascript code

Vincent Bernat wrote: > >Notably, one of the tool is Grunt and its myriad of plugins. Even if >Grunt was in Debian, we would also need Gulp, then Broccoli, because in >Javascript, there is always someone thinking that it should be possible >to do better. We need to leave the Javascript ecosystem ma

Re: Security concerns with minified javascript code

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Tue, Aug 25, 2015 at 11:13:15PM +0200, Vincent Bernat wrote: > ❦ 25 août 2015 17:58 GMT, Bas Wijnen  : > > > I don't see why javascript minification would be different from C > > compilation > > in a way that would lead to a different way of hand

Re: Security concerns with minified javascript code

❦ 25 août 2015 22:37 GMT, Bas Wijnen  : >> We need to leave the Javascript ecosystem mature a bit more but in the >> meantime, a bit of tolerance would be appreciated > > The minifier is a compiler. If it's not in main, files that are compiled with > it cannot be in main. For javascript, the ea

Re: Security concerns with minified javascript code

❦ 25 août 2015 22:46 +0100, Steve McIntyre  : >>Notably, one of the tool is Grunt and its myriad of plugins. Even if >>Grunt was in Debian, we would also need Gulp, then Broccoli, because in >>Javascript, there is always someone thinking that it should be possible >>to do better. We need to leave

Re: Security concerns with minified javascript code

> For years, we have been able to ship generated files without checking if > they can really be built from sources (for example, autoconf stuff). And > JS stuff should comply to stricter standards from day one? JS stuff has been in Debian for a long time; it isn't fair to say that this is day one

Re: Security concerns with minified javascript code

❦ 26 août 2015 15:44 +1000, Riley Baird  : >> For years, we have been able to ship generated files without checking if >> they can really be built from sources (for example, autoconf stuff). And >> JS stuff should comply to stricter standards from day one? > > JS stuff has been in Debian for a

Re: Security concerns with minified javascript code

Vincent Bernat writes: > ❦ 25 août 2015 22:46 +0100, Steve McIntyre  : > >>>Notably, one of the tool is Grunt and its myriad of plugins. Even if >>>Grunt was in Debian, we would also need Gulp, then Broccoli, because in >>>Javascript, there is always someone thinking that it should be possible >

Re: Security concerns with minified javascript code

❦ 26 août 2015 09:04 +0200, Simon Josefsson  : Notably, one of the tool is Grunt and its myriad of plugins. Even if Grunt was in Debian, we would also need Gulp, then Broccoli, because in Javascript, there is always someone thinking that it should be possible to do better. We need

Re: Security concerns with minified javascript code

On Wed, Aug 26, 2015 at 12:04 AM, Simon Josefsson wrote: > Vincent Bernat writes: > >> ❦ 25 août 2015 22:46 +0100, Steve McIntyre : >> Notably, one of the tool is Grunt and its myriad of plugins. Even if Grunt was in Debian, we would also need Gulp, then Broccoli, because in Javascr

Re: Security concerns with minified javascript code

> Sure, you can proofread a 30k-line configure script without a > problem. So, the condition is now "must be generated from source only if > the generated from is hard-but-not-impossible to read". Several times over the last year I have modified the output form of autoconf directly when doing mino

Re: Security concerns with minified javascript code

Vincent Bernat writes: > ❦ 25 août 2015 22:46 +0100, Steve McIntyre  : > >>>Notably, one of the tool is Grunt and its myriad of plugins. Even if >>>Grunt was in Debian, we would also need Gulp, then Broccoli, because in >>>Javascript, there is always someone thinking that it should be possible >

Re: Security concerns with minified javascript code

❦ 26 août 2015 20:58 +1000, Riley Baird  : >> I would also like to stress that all this stuff is DFSG-compliant. > > Doesn't the DFSG require source code, as well as a free license? Yes and both of them are here. Only the build method is either unavailable, unspecified or needing network connec

Re: Security concerns with minified javascript code

Vincent Bernat writes ("Re: Security concerns with minified javascript code"): > My point is not that's a good idea. My point is that this has been > tolerated for years while there was an easy workaround solution (running > autoreconf). It was only tolerated because pro

Re: Security concerns with minified javascript code

❦ 26 août 2015 12:09 +0100, Philip Hands  : > I note that this page: > > https://wiki.debian.org/Javascript/Nodejs/Tasks/grunt > > was last touched in March, before the last thread in which you told us > that packaging grunt is very hard: > > https://lists.debian.org/debian-devel/2015/04/msg0

Re: Security concerns with minified javascript code

❦ 26 août 2015 13:01 +0100, Ian Jackson  : >> It's "unfair" to ask packages using JS stuff to be >> "perfect" right now while the difficulties are far greater. > > I'm sorry to say that the very fact that the difficulties are more > severe is an argument /against/ tolerating un-rebuilt minified j

Re: Security concerns with minified javascript code

On Wed, Aug 26, 2015 at 12:28:22AM -0700, Vincent Cheng wrote: > In that case, perhaps those who are most vocally in favour of > enforcing build-time javascript minification would care to work on a > debhelper addon to do so (similar to how dh-autoreconf makes dealing That to me seems the best way

Re: Security concerns with minified javascript code

Craig Small wrote: >On Wed, Aug 26, 2015 at 12:28:22AM -0700, Vincent Cheng wrote: >> In that case, perhaps those who are most vocally in favour of >> enforcing build-time javascript minification would care to work on a >> debhelper addon to do so (similar to how dh-autoreconf makes dealing >That t

Re: Security concerns with minified javascript code

Vincent Bernat writes: > ❦ 26 août 2015 12:09 +0100, Philip Hands  : > >> I note that this page: >> >> https://wiki.debian.org/Javascript/Nodejs/Tasks/grunt >> >> was last touched in March, before the last thread in which you told us >> that packaging grunt is very hard: >> >> https://lists.

Re: Security concerns with minified javascript code

Vincent Bernat writes ("Re: Security concerns with minified javascript code"): > In the Debian context, the problem is hard. But if you allow network > access and execution of arbitrary code recovered from some random > registry, rebuilding the minified version from the unmini

Re: Security concerns with minified javascript code

Ian Jackson writes: > Vincent Bernat writes ("Re: Security concerns with minified javascript code"): >> In the Debian context, the problem is hard. But if you allow network >> access and execution of arbitrary code recovered from some random >> registry, rebuildin

Re: Security concerns with minified javascript code

❦ 26 août 2015 09:27 -0700, Russ Allbery  : >>> In the Debian context, the problem is hard. But if you allow network >>> access and execution of arbitrary code recovered from some random >>> registry, rebuilding the minified version from the unminified one is >>> quite trivial. > >>> I know how i

Re: Security concerns with minified javascript code

Hello list, On 26.08.2015 15:56, Philip Hands wrote: > Vincent Bernat writes: > >> [...] >> 3. ship a pre-compiled/minified version of the library with sources. >> >> I know this sucks, but if I have to pick my poison, I'll pick the last >> one. I have tried the second solution in the past, nob

Re: Security concerns with minified javascript code

On Aug 26, Russ Allbery wrote: > Maybe there's some pragmatic approach that I haven't thought of yet that > will make this less painful. That's what I'm hoping for. Me too: I really care that Debian will continue to be relevant. -- ciao, Marco pgpMdNWptTf8g.pgp Description: PGP signature

Re: Security concerns with minified javascript code

On Wed, Aug 26, 2015 at 1:42 PM, Vincent Bernat wrote: > Yes and both of them are here. Only the build method is either > unavailable, unspecified or needing network connectivity. Sounds like something that should be in contrib? -- bye, pabs https://wiki.debian.org/PaulWise

Re: Security concerns with minified javascript code

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wed, Aug 26, 2015 at 07:35:01AM +0200, Vincent Bernat wrote: > ❦ 25 août 2015 22:37 GMT, Bas Wijnen  : > > >> We need to leave the Javascript ecosystem mature a bit more but in the > >> meantime, a bit of tolerance would be appreciated > > > > The

Re: Security concerns with minified javascript code

Bas Wijnen 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 versi

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 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

Re: Security concerns with minified javascript code

❦ 27 août 2015 22:04 GMT, Bas Wijnen  : >> > The minifier is a compiler. If it's not in main, files that are compiled >> > with >> > it cannot be in main. For javascript, the easy solution is to not use the >> > compiler. Non-minified code works fine. >> >> Non-minified code is decomposed in

Re: Security concerns with minified javascript code

❦ 28 août 2015 01:46 GMT, Bas Wijnen  : > 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 t

Re: Security concerns with minified javascript code

Vincent Bernat writes: > 28 août 2015 01:46 GMT, Bas Wijnen  : > >> 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 minif

Re: Security concerns with minified javascript code

❦ 28 août 2015 08:22 +0100, Philip Hands  : >>> 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 exa

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 tha

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

❦ 28 août 2015 10:29 +0200, Samuel Thibault  : >> 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 in main? [...

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  : > > >> 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 a

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 a

Re: Security concerns with minified javascript code

On Fri, 28 Aug 2015 10:45:16 +0200 Samuel Thibault 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 > as well just s

Re: Security concerns with minified javascript code

❦ 28 août 2015 10:32 +0100, Neil Williams  : > 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 feature. The JS

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 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

Re: Security concerns with minified javascript code

❦ 28 août 2015 12:03 +0200, Samuel Thibault  : > 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 anything.

Re: Security concerns with minified javascript code

Dmitry Smirnov 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 against m

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 yui-com

Re: Security concerns with minified javascript code

Neil Williams 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 correct. > Usable s

Re: Security concerns with minified javascript code

Russ Allbery wrote: >Neil Williams 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. Because the >dep

Re: Security concerns with minified javascript code

Steve McIntyre writes: > Depressingly, it seems a lot of the same web typists don't have any > problems with doing the equivalent of "curl http://some.site/install.sh > | sudo bash" . That doesn't mean we have to do the same in Debian. If > there's no sensible way to do controlled web development

Re: Security concerns with minified javascript code

On Fri, Aug 28, 2015 at 4:12 PM, Jean-Michel Vourgère 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 possible, but

Re: Security concerns with minified javascript code

On Fri, Aug 28, 2015 at 4:12 PM, Jean-Michel Vourgère 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 possible, but

Re: Security concerns with minified javascript code

❦ 28 août 2015 17:37 +0100, Steve McIntyre  : >>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. Because the >>dependency installation process is so

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

Re: Security concerns with minified javascript code

Steve Langasek 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 practical as we

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 pi

Re: Security concerns with minified javascript code

❦ 29 août 2015 19:12 -0700, Steve Langasek  : > 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 > lesson), there's 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 o

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. >

Re: Security concerns with minified javascript code

❦ 30 août 2015 11:52 GMT, Bas Wijnen  : >> 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 changes to

Re: Security concerns with minified javascript code

On 08/28/2015 01:14 AM, Russ Allbery wrote: > Bas Wijnen 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 contrib, > or

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 non-curr

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 ene

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 a symlink to the > p

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 of attention to this

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 m

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 than the minified ones.

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 pri

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 i

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 impl

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 t

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 much from non minifi

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 it to be a "preferr

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 pro

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, -Nikolaus -- GPG encrypt

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 doesn't suffer much fr

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: https://mathiasbynens.be/demo/jquery-size -- Don't sacrif

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 view, it isn't: > > >

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 about gzip encoding). > > See: > https:

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 yo

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 buildd is responsibl

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 when loading a web pag

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 pro

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

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

❦ 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 >> handling (through loade

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? (Don't forget about

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 > JS files if minifyi

  1   2   >