[
https://issues.apache.org/jira/browse/COMPRESS-299?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14295473#comment-14295473
]
Tim Allison commented on COMPRESS-299:
--------------------------------------
I thought that they had. :) Today, I went to
[here|http://www.oracle.com/technetwork/java/javase/downloads/jce-7-download-432124.html]
and downloaded the zip. Inside, I saw two jars, local_policy.jar and
US_export_policy.jar. When I went to drop them in my jre/lib/security folder,
I saw that there were two files of the same size (roughly, didn't check actual
byte length) and names already there. I overwrote the existing jars with ones
I pulled freshly from the web, and the unit test now works.
So, once I overwrote the 2015 jars with jars from 2011 (as pulled from the site
above), the test now passes. Did java change something in those jars?! It
doesn't feel right to overwrite new jars with old jars. :)
> Issue with a 7z encrypted file
> ------------------------------
>
> Key: COMPRESS-299
> URL: https://issues.apache.org/jira/browse/COMPRESS-299
> Project: Commons Compress
> Issue Type: Bug
> Reporter: Tim Allison
> Priority: Minor
> Attachments: test7Z_protected_passTika.7z
>
>
> A file that we are using to test SevenZ on Tika is failing in some
> environments.
> I tested the soon to be attached file with commons compress trunk and
> received this exception:
> {noformat}
> java.security.InvalidKeyException: Illegal key size
> at javax.crypto.Cipher.checkCryptoPerm(Cipher.java:1024)
> at javax.crypto.Cipher.implInit(Cipher.java:790)
> at javax.crypto.Cipher.chooseProvider(Cipher.java:849)
> at javax.crypto.Cipher.init(Cipher.java:1348)
> at javax.crypto.Cipher.init(Cipher.java:1282)
> at
> org.apache.commons.compress.archivers.sevenz.AES256SHA256Decoder$1.init(AES256SHA256Decoder.java:98)
> at
> org.apache.commons.compress.archivers.sevenz.AES256SHA256Decoder$1.read(AES256SHA256Decoder.java:117)
> at java.io.DataInputStream.readUnsignedByte(DataInputStream.java:288)
> at org.tukaani.xz.rangecoder.RangeDecoderFromStream.<init>(Unknown
> Source)
> at org.tukaani.xz.LZMAInputStream.initialize(Unknown Source)
> at org.tukaani.xz.LZMAInputStream.initialize(Unknown Source)
> at org.tukaani.xz.LZMAInputStream.<init>(Unknown Source)
> at
> org.apache.commons.compress.archivers.sevenz.Coders$LZMADecoder.decode(Coders.java:114)
> at
> org.apache.commons.compress.archivers.sevenz.Coders.addDecoder(Coders.java:78)
> at
> org.apache.commons.compress.archivers.sevenz.SevenZFile.buildDecoderStack(SevenZFile.java:864)
> at
> org.apache.commons.compress.archivers.sevenz.SevenZFile.buildDecodingStream(SevenZFile.java:831)
> at
> org.apache.commons.compress.archivers.sevenz.SevenZFile.getNextEntry(SevenZFile.java:153)
> at
> org.apache.commons.compress.archivers.sevenz.SevenZFileTest.testTikaEncryptedFile(SevenZFileTest.java:215)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at junit.framework.TestCase.runTest(TestCase.java:176)
> at junit.framework.TestCase.runBare(TestCa
> {noformat}
> This is the unit test:
> {noformat}
> public void testTikaEncryptedFile() throws Exception {
> String password = "Tika";
> SevenZFile sevenZFile = new
> SevenZFile(getFile("test7Z_protected_passTika.7z"),
> password.getBytes("UnicodeLittleUnmarked"));
> try {
> SevenZArchiveEntry entry = sevenZFile.getNextEntry();
> assertEquals("text.txt", entry.getName());
> } finally {
> sevenZFile.close();
> }
> }
> {noformat}
> Environment: Windows 7, Java 1.7.0_76-b13.
> No problem on RHEL 1.7.0_75
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
