Ian Jackson <ijack...@chiark.greenend.org.uk> 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, rebuilding the minified version from the unminified one is >> quite trivial. >> I know how it sounds. > Well, we don't normally consider a program free if the only way users > can modify it is something like that. Yeah. The problem is that nearly the entire rest of the free sofware world *does* consider programs like that free. (See the Ruby, Java, and Go communities, among many others, that have standard build and deploy tools that work that way.) And therefore structures their software to assume those capabilities, does not work on removing those dependencies, does not accept patches to improve the situation, etc. This is, *very* widely, considered something that only Debian cares about. I'm not saying that they're right, just that the amount of effort then required to package that software in Debian is huge, and mostly outside the reach of the typical packaging team or packaging volunteer. Our reaction has been varied. The Ruby team put a ton of work into developing a standardized framework for doing the right thing, and took a ton of upstream heat for doing so (some of which continues to this day). For Java, we largely just gave up -- we package some portions of the Java ecosystem, but vast amounts of it are just missing because the problem was too hard, and packaging any major Java application is a huge endeavor. Javascript is particularly challenging because, these days, it's showing up *everywhere* in *everything*, and shipping minified Javascript is widely accepted and nearly universal best practice. So unlike with Java, this doesn't affect just one language community and the applications that come out of that community. It's affecting pretty large swaths of interesting applications managed by a huge variety of different packaging teams. I'm not saying that we should necessarily relax our standards. I completely agree with the standards, and have been very happy to see the motion on similar things, such as Autoconf. But as one of the people who looked at large Java applications in the past and just gave up, I think it's important that we have a realistic understanding of just what we're asking of packagers and the extent to which we're swimming upstream here. 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. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>