Le 27/08/2017 à 18:48, Thorsten Alteholz a écrit : > ok, but this seems to be wrong. If scala-tools-sbinary really is the > last package, it must not contain any binary jar files but could use > packages from the archive, right?
My understanding it that it's actually the last dependency required before we can start removing the binaries from the other sbt related packages. > I just had a quick lock at the embedded org.beanshell > and didn't find any dependency on sbt for that tool. So at least this > jar file could be handled better. While talking about beanshell, the > sources on github contain files under a BSD-license. In your > debian/copyright you just mention the Apache license and one copyright > holder for it. There seems to be much room for improvement in your > debian/copyright. Luckily bsh in version 2.04b is already in Debian and > the debian/copyright of this package says it is under LGPL. I am sorry, > but your debian/copyright is a mess and it does not help that there are > lots of binary blobs included. > Further there is CVE-2016-2510, which is fixed in 2.0b6 and not in your > embedded version 2.0b4. FWIW, the beanshell 2.0b4 vs 2.0b6 issue has been discussed in #700610. beanshell isn't to blame for the vulnerability, it's a common issue affecting Java applications deserializing untrusted data without sanitizing it. sbt is most certainly not affected by this. That said, I agree the beanshell jar was probably not necessary in the bootstrap tarball. > From my point of view scala-tools-sbinary can not be accepted yet. Assuming we get debian/copyright in a better shape and remove the binaries already packaged from the tarball, it is ok to upload scala-tools-sbinary to main to complete the bootstrapping? Emmanuel Bourg __ This is the maintainer address of Debian's Java team <http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-java-maintainers>. Please use debian-j...@lists.debian.org for discussions and questions.