user id 'xxx' is too big ( > 2097151 ) when using commons-compress 1.21 with large user ID #4384
Labels
Milestone
Comments
|
I'm experiencing the same issue. It'd be resolved by setting |
|
Hey @schmidt-galen-heb, @batt842 Thanks for bringing this to our attention and already providing a possible explanation and fix. |
|
Opened #4388. I built it locally using
|
This was referenced Sep 7, 2021
rnorth
pushed a commit
that referenced
this issue
Sep 8, 2021
kaklakariada
added a commit
to exasol/tableau-connector
that referenced
this issue
Oct 20, 2021
user id 'xxx' is too big ( > 2097151 ) when using commons-compress 1.21 with large user ID testcontainers/testcontainers-java#4384
kaklakariada
added a commit
to exasol/tableau-connector
that referenced
this issue
Oct 27, 2021
* Update name of ODBC driver * Update ODBC manifest * Add JDBC connector * Add JDBC capabilities * Describe installation of jdbc driver * Adapt capabilities for jdbc driver * Add fingerprint * Configure tdvt * Add data source tests * Add results workbook * Update data source * Update test result workbook * Configure string trim for jdbc * Add test with bad password * Skip string.split test: function not supported by Exasol * Rename column zzz2 to zzz * Remove trailing spaces when extracting parts of a date * Remove duplicate space * Add rationale for skipping the 'split' function tests * Change test user name to be equal to odbc tests * Skip test for time data type TIME not supported by Exasol * Rename tdvt folder to odbc * Adapt hostname for jdbc tests * Adapt odbc tests to run * Unify test configuration for jdbc & odbc * Fix odbc issues with spaces Remove trimming capabilities that hide issue with trailing spaces in TO_CHAR() * Configure max number of threads to 1 * Remvove argument for number of threads This is now configured in the ini file * Add comment about failing tests * Ignore Eclipse config files * Update instructions for building the dockerfile * Update dependencies * Improve formatting of readme * Add HtmlUnit driver * Use Exasol 7.1.1, improve error handling * Improve error handling in shell script * Cleanup * Adapt configuration to Eclipse 2021-09 * Validate & package jdbc connector * Improve pom setup * Cleanup tests: remove unused ports * Read properties file in Java code to avoid having to set environment variables when running tests from the IDE. * Upgrade testcontainers to fix uploading files to the container user id 'xxx' is too big ( > 2097151 ) when using commons-compress 1.21 with large user ID testcontainers/testcontainers-java#4384 * Adapt UI-Tests to new Connector name / Tableau version * Run tests in headless mode * Document ui-test setup * Build JDBC url with fingerprint and certificate validation arguments * Update fingerprint in connection files * Add developer guide * Move test instructions to developer guide * Add connection dialog screenshot * Configure Eclipse formatter to never join already wrapped lines * Extract base class for JDBC & ODBC connector tests * Add UI tests for JDBC connector * Fix failing StaplesDataTest See tableau/connector-plugin-sdk#871 for details. * Add changelog, improve documentation * #22 Implement review findings by @AnastasiiaSergienko * Apply suggestions from code review Co-authored-by: Anastasiia Sergienko <46891819+AnastasiiaSergienko@users.noreply.github.com> * Implement review findings by @AnastasiiaSergienko Co-authored-by: Anastasiia Sergienko <46891819+AnastasiiaSergienko@users.noreply.github.com>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
I upgraded
org.apache.commons/commons-compressto1.21in our project to address CVE-2021-36090, and TestContainers started failing to start with the following error:My account is provisioned via a large enterprise system, so my User ID is indeed larger than
2097151.I was using TestContainers
1.51.1, but I tried upgrading to1.16.0and received the same failure.I'm unclear why the version bump caused the issue since the relavent code block appears to be the same in
commons-compress1.20 and 1.21, but I believe the solution is just to set the TarArchiveOutputStream.bigNumberMode to TarArchiveOutputStream.BIGNUMBER_POSIX in addition to TarArchiveOutputStream.longFileModeThe text was updated successfully, but these errors were encountered: