Re: [compress] Strong Crypto in Tests

2013-10-23 Thread Stefan Bodewig
On 2013-10-24, Benedikt Ritter wrote: > I don't see a reason to wait for 2.x before updating to JUnit 4. The > old tests will be executable without changes. There already are 4.x and 3.x tests mixed up. > Am I missing something here? It needs somebody to do it. As I expet us to rewrite all tes

Re: [compress] Strong Crypto in Tests

2013-10-23 Thread Benedikt Ritter
2013/10/24 Gary Gregory > On Thu, Oct 24, 2013 at 1:45 AM, Benedikt Ritter >wrote: > > > > > > > Send from my mobile device > > > > > Am 23.10.2013 um 16:12 schrieb Stefan Bodewig : > > > > > >> On 2013-10-23, Gary Gregory wrote: > > >> > > >> Consider using JUnit's Assume to skip testing, this

Re: [compress] Strong Crypto in Tests

2013-10-23 Thread Gary Gregory
On Thu, Oct 24, 2013 at 1:45 AM, Benedikt Ritter wrote: > > > Send from my mobile device > > > Am 23.10.2013 um 16:12 schrieb Stefan Bodewig : > > > >> On 2013-10-23, Gary Gregory wrote: > >> > >> Consider using JUnit's Assume to skip testing, this will allow IDEs and > >> tools to know a test has

Re: [compress] Strong Crypto in Tests

2013-10-23 Thread Benedikt Ritter
Send from my mobile device > Am 23.10.2013 um 16:12 schrieb Stefan Bodewig : > >> On 2013-10-23, Gary Gregory wrote: >> >> Consider using JUnit's Assume to skip testing, this will allow IDEs and >> tools to know a test has been skipped. > > Unfortunately the test like many of Compress' tests

Re: [compress] Strong Crypto in Tests

2013-10-23 Thread Stefan Bodewig
On 2013-10-23, Gary Gregory wrote: > Consider using JUnit's Assume to skip testing, this will allow IDEs and > tools to know a test has been skipped. Unfortunately the test like many of Compress' tests is in JUnit 3.x land - something to change if we ever get 2.x off the ground. Stefan

Re: [compress] Strong Crypto in Tests

2013-10-23 Thread Stefan Bodewig
On 2013-10-23, Mark Fortner wrote: > As you're probably aware, aes is export restricted. Commons Compress already has a crypto notice, see also 7z uses 256bit AES when encrypting so if we want to provide code that can read encrypted archives there is lit

Re: [compress] Strong Crypto in Tests

2013-10-23 Thread Gary Gregory
Consider using JUnit's Assume to skip testing, this will allow IDEs and tools to know a test has been skipped. If you use a conditional in the test code, there is no possible feedback. Gary On Wed, Oct 23, 2013 at 5:15 AM, Stefan Bodewig wrote: > On 2013-10-23, Emmanuel Bourg wrote: > > > The

Re: [compress] Strong Crypto in Tests

2013-10-23 Thread Stefan Bodewig
On 2013-10-23, Paul Benedict wrote: > In my own research on strong crypto, I found out that US law allows > strong crypto to be exported for open source software. That was some > provision recently carved out in the last 10 years. I think there are > some limitations and procedures wrapped around

Re: [compress] Strong Crypto in Tests

2013-10-23 Thread Paul Benedict
In my own research on strong crypto, I found out that US law allows strong crypto to be exported for open source software. That was some provision recently carved out in the last 10 years. I think there are some limitations and procedures wrapped around it -- like submitting the URL to the source c

Re: [compress] Strong Crypto in Tests

2013-10-23 Thread Mark Fortner
As you're probably aware, aes is export restricted. So it might be better to simply check for the availability of a particular encryption algorithm before running a test and avoid making restricted libraries generally available. Mark On Oct 23, 2013 6:10 AM, "Stefan Bodewig" wrote: > On 2013-10-

Re: [compress] Strong Crypto in Tests

2013-10-23 Thread Stefan Bodewig
On 2013-10-23, Bear Giles wrote: > Should that be PKCS7Padding? Or would that be worse - I don't recall > if it's one of the "must have" paddings in the spec. 7z uses "AES/CBC/NoPadding" and that's what I use during the check inside the unit tests as well now. Stefan ---

Re: [compress] Strong Crypto in Tests

2013-10-23 Thread Bear Giles
Should that be PKCS7Padding? Or would that be worse - I don't recall if it's one of the "must have" paddings in the spec. http://crypto.stackexchange.com/questions/9043/what-is-the-difference-between-pkcs5-padding-and-pkcs7-padding In practice it's unlikely that a software-based crypto provider w

Re: [compress] Strong Crypto in Tests

2013-10-23 Thread Stefan Bodewig
On 2013-10-23, Jörg Schaible wrote: > boolean supportedKeyLength(int keyLen) throws NoSuchAlgorithmException > { >if (Cipher.getMaxAllowedKeyLength("AES/ECB/PKCS5Padding") < keyLen) { > System.err.println("WARNING: " + getName() >+ " not executed, environment does not support "

Re: [compress] Strong Crypto in Tests

2013-10-23 Thread Jörg Schaible
Stefan Bodewig wrote: > On 2013-10-23, Emmanuel Bourg wrote: > >> The test coverage is much better, thank you Stefan. > > Thank you for making me find a serious bug by pointing out the low > coverage :-) > >> test7zDecryptUnarchive failed on Linux using the Java 6 JDK (not >> OpenJDK6) due to t

[compress] Strong Crypto in Tests

2013-10-23 Thread Stefan Bodewig
On 2013-10-23, Emmanuel Bourg wrote: > The test coverage is much better, thank you Stefan. Thank you for making me find a serious bug by pointing out the low coverage :-) > test7zDecryptUnarchive failed on Linux using the Java 6 JDK (not > OpenJDK6) due to the lack of the strong crypto policy. T