Dear Maintainer, I do not believe that this bug constitutes a security vulnerability or that it deserves grave severity.
To be exploited remotely, you have to execute an untrusted XSLT stylesheet, which is similar to executing untrusted arbitrary code, and is a bad idea for reasons much more severe than this DoS. For example, using external entities and the document() function, an untrusted XSLT stylesheet can read arbitrary files from the filesystem and upload their contents to a Web server on the Internet. So in order to safely execute an untrusted XSLT stylesheet, you really need to run the XSLT processor in a sandbox with restricted filesystem and network access. At that point you might as well use ulimit or cgroups to prevent resource consumption such as from infinite recursion. As for exploiting locally, there are already a plethora of ways for a local user to DoS the system, such as by running a fork bomb in bash. In these ways, Xalan is similar to an interpreter like bash or perl. The fact that malicious programs can do great harm to a system if interpreted by bash or perl does not constitute a security vulnerability in bash or perl, and nor should it in Xalan. I therefore propose that the severity of this bug be reduced to important or normal so that Xalan can migrate to Testing. It would be a shame for Xalan to not make it into Jessie because of this. Regards, Andrew -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
