scala-tools-sbinary_0.4.2+2.11.M5-1_amd64.changes REJECTED

[Emmanuel Bourg]

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