On 2017-03-10 15:34, Tobias Bocanegra wrote:
Hi Julian, the references to the "unstable" versions are unfortunate, but they don't have impact of the operation. also, all the test pass so far. the only user of commons-collections is vault-cli, and I don't think that this is vulnerable to the serilization vulnerability.
That may be true, but it keeps the users of vault wondering whether everything is ok. It's simply better to use the correct version in the first place.
here's the list of bundled libraries in vault-cli: commons-cli-2.0-mahout.jar commons-codec-1.10.jar commons-collections-3.2.1.jar commons-io-2.4.jar commons-jci-fam-1.0.jar commons-logging-1.0.3.jar commons-logging-api-1.1.jar
Unless I'm missing something obvious, we should use the latest library version that works for the Java version we need to support.
diffutils-1.2.1.jar guava-15.0.jar httpclient-4.5.2.jar httpcore-4.4.4.jar httpmime-4.5.2.jar
httpclient and -mime are 4.5.3 in jackrabbit right now.
jackrabbit-api-2.13.7.jar jackrabbit-jcr-client-2.13.7.jar jackrabbit-jcr-commons-2.13.7.jar jackrabbit-jcr2spi-2.13.7.jar jackrabbit-spi-2.13.7.jar jackrabbit-spi-commons-2.13.7.jar jackrabbit-spi2dav-2.13.7.jar jackrabbit-webdav-2.13.7.jar
These should use a stable release. We can't tell people not to use these if we do so ourselves without a good reason.
however, if you think this is really a no go, please indicate which versions you would use, and I will update them for the next the release, if the vote fails.
Yes, I consider this a showstopper. Unless there's an emergency you need to deal with, I'd cancel this release, update the dependencies, and cut a new one.
thanks. regards, toby btw: there should be a mechanism to mark libraries as invalid/revoked so that they can't be referenced by other projects.
Yes - or at least generate fat warnings. Best regards, Julian
