I doubt there's any more leaks of this, but it's possible it leaks transitively, via one of those dependencies in our "allow" ruleset for apilyzer-maven-plugin: https://github.com/apache/accumulo/blob/master/core/pom.xml#L191-L212
However, users can avoid issues with the older version by simply deploying 1.10 instead of the 1.6 that we've built against. We could further mitigate this by changing the version that ships in our assembly, to make it newer than the version that we compile against. If there is an issue with commons-collections, specifically, we can exclude and/or override that version from the commons-configuration 1.6 declaration in the POM. But again, users could simply drop in the newer version of that. On Tue, Apr 2, 2019 at 9:38 AM Sean Busbey <[email protected]> wrote: > > reviewing my notes from the time period, it looks like I was > attempting to make sure we didn't pull in a commons-collections > version with open CVEs. > > have we already confirmed that no part of commons-configuration leaks > into the public API for 2.0? > > On Mon, Apr 1, 2019 at 11:22 AM Mike Miller <[email protected]> wrote: > > > > So I am trying to track down why we upgraded commons config from 1.6 to > > 1.10. This upgrade is problematic for a bug fix release for a few > > reasons. For one, the changes in 06d80292 > > <https://github.com/apache/accumulo/pull/659> break semver by adding new > > methods inherited from ClientConfiguration. Then Keith ran into problems > > trying to run Map Reduce for continuous ingest. Keith opened an issue here: > > https://github.com/apache/accumulo/issues/1065 > > > > I don't think this change should go in a bug fix release but I think it > > would be good to know why this was done in the first place. I am going to > > test a branch with this upgrade reverted. > > > > -- > busbey
