Wheeler: Insecure open source software libraries? [LWN.net]

Wheeler: Insecure open source software libraries?

Posted Apr 10, 2012 20:05 UTC (Tue) by Cyberax (✭ supporter ✭, #52523)
In reply to: Wheeler: Insecure open source software libraries? by rqosa
Parent article: Wheeler: Insecure open source software libraries?

>According to here, mvn package does bundle dependencies when building a package that has <packaging>war</packaging> in its POM.

Nope, maven-war-plugin does it. By itself Maven doesn't do any packaging.

Besides, even maven-war-plugin doesn't pack all dependencies into one JAR file, it simply copies them into WEB-INF/lib directory of a web application.

>That's because old package versions don't remain in the repository, and it doesn't allow installing multiple versions of the same package in parallel.

Yup. That's why it's different from Maven.

>I responded that Java already tried this approach, which is what's to blame for the problem (insecure bundled libraries) that the original article is about, and the existence of Maven shows that Java developers are migrating away from the notion of a single "static API" to a system of multiple separately-versioned library APIs with a tree of dependencies among them

Nope they don't. Maven is a freaking _build_ tool, it's NOT a package management tool. So it HAS to work with versions and dependencies.

You mean it's similar because it has a notion of dependency tree? Duh. Even 'make' has it.

(Log in to post comments)

Wheeler: Insecure open source software libraries?

Posted Apr 10, 2012 21:17 UTC (Tue) by rqosa (subscriber, #24136) [Link]

> Nope, maven-war-plugin does it.

That fine distinction doesn't matter here.

> Besides, even maven-war-plugin doesn't pack all dependencies into one JAR file, it simply copies them into WEB-INF/lib directory of a web application.

But the WEB-INF/lib directory is in the WAR file — therefore the applications and its dependencies are bundled into a single archive file.

> Maven is a freaking _build_ tool, it's NOT a package management tool.

It's obviously more than just a build tool; there are plenty of build tools (probably most of them) that have neither transitive dependency resolution for external dependencies nor the ability to download said external dependencies from a central repository.

> You mean it's similar because it has a notion of dependency tree?

No. It's similar because it uses transitive dependency resolution to determine what packages from a central package repository (one that's hosted on a single public server on the Internet and used by default on each Maven installation, that is; not just something that's on the local HDD) are required by the project to be built, then downloads them from there and uses them to build and/or run the project.

> Duh. Even 'make' has it.

Make's dependency tree doesn't extend beyond the files that are part of the project to be built; it doesn't have any real notion of external dependencies. Higher-level build tools like cmake and autoconf/automake have a notion of immediate external dependencies, but no tree of external dependencies (and therefore no transitive dependency resolution for external dependencies) and no ability to retrieve dependencies from a central repository.

(Though it's possible to build an external-dependency-resolution system on top of make, as the FreeBSD ports tree shows — but I consider the FreeBSD ports tree to be a package manager too.)

Wheeler: Insecure open source software libraries?

Posted Apr 10, 2012 22:07 UTC (Tue) by khim (subscriber, #9252) [Link]

I still don't understand what you are trying to discuss here. Yes, maven is similar to Linux distribution - so what? Linux distributions are quite good for development. They are abysmal for deplayment. And here Maven offers the solution: prepare package suitable for use with a given version of J2EE ABI. Administrator does not need to know what dependencies are there in a given package - s/he only need to know version of J2EE needed by a given WAR and version of J2EE supported by given server. Easy, simple, unambiguous.

In a sense this approach nicely combines Linux distribution development advantages with Appstore-style deployment advantages. The only problem: it's tied to Java which by itself does not form suitable desktop environment.

Wheeler: Insecure open source software libraries?

Posted Apr 10, 2012 23:02 UTC (Tue) by rqosa (subscriber, #24136) [Link]

> I still don't understand what you are trying to discuss here.

I've explained this twice already, here:

even though Java SE [actually EE] has a fairly large standard "platform API", it's still not enough for all apps, and that's why Java developers now use a package repository with a constantly-changing selection of libraries (unlike the set-in-stone "platform API") and also a tree of dependencies together with dependency resolution in the package manager (unlike the supposedly "more effective" Android Market and iOS App Store, which lack dependency resolution and therefore require all packages to depend on the "platform API" only).

and here:

drag was saying that there should be a "versioned […] static API" for the entire set of userland APIs on Linux; I responded that Java already tried this approach, which is what's to blame for the problem (insecure bundled libraries) that the original article is about, and the existence of Maven shows that Java developers are migrating away from the notion of a single "static API" to a system of multiple separately-versioned library APIs with a tree of dependencies among them (i.e. exactly what isn't done on iOS and Android, the OSes drag says have "more effective" package management).

TL;DR version: Any "standard platform API" will never be enough for all apps on the platform; this is why developers using Java (which has a very large "standard platform API") now use a central package repository with an ever-increasing selection of libraries and a dependency tree.

> In a sense this approach nicely combines Linux distribution development advantages with Appstore-style deployment advantages.

I suppose it does help solve the problem of insecure-bundled-libraries, because it makes it easier to track the newest library versions. But still, it seems that the insecure-bundled-libraries problem persists, because Java library developers tend to follow the convention that "release version number == API version number" and break API compatibility often (leaving the old API versions unmaintained), which leads to "endemic "pinning" of dependencies to specific version numbers".

Wheeler: Insecure open source software libraries?

Posted Apr 10, 2012 23:56 UTC (Tue) by rqosa (subscriber, #24136) [Link]

And also, when using Maven to build apps as WARs (i.e. "Appstore-style deployment"), there's still the issue of multiple copies of the same library (leading to wasted storage space and RAM, and to a single library bugfix requiring an update for all apps using it).

Wheeler: Insecure open source software libraries?

Posted Apr 11, 2012 9:56 UTC (Wed) by alankila (subscriber, #47141) [Link]

As an application developer these are acceptable tradeoffs. Disk space is very cheap, and jar files can not truly be shared between jvm processes anyway because the jar file is not useful per se, the class files are usually deflate-compressed, and they contain symbolic references that are resolved at class loading time to speed up interpretation. Then there's the whole jit compilation step whose result is affected by the surrounding code that uses the library.