Re: [Fileupload] CVE security page and site distribution

Hello Bernd, I've fixed this in revision 14202 in the dist area. Does this work for you? Benedikt Bernd schrieb am Di., 28. Juni 2016 um 13:38 Uhr: > Hello, > > I was trying to come up with a Victims-cve-db entry for CVE-2016-3092 and I > noticed a few odd things ( >

Re: [crypto] Camel case for names

These are mostly internal classes, so we can change the names for every release if we like (now that the names are no longer embedded in constants). But it would be better to fix them now if there's agreement. On 30 June 2016 at 10:51, Stian Soiland-Reyes wrote: > It's tricky

Re: [crypto] Camel case for names

Le 30/06/2016 à 11:51, Stian Soiland-Reyes a écrit : > +1 OpenSSLCipher +1 as well Emmanuel Bourg - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org

Re: [crypto] Camel case for names

It's tricky to have a hard rules for consistent acronyms in CamelCase, some inconsistency will eventually sneak in to break the symmetry. In Commons RDF we faced this in that we had an interface "RDFTermFactory", "Triple" and "IRI" -- but then I added JSON-LD Java bindings and didn't want to

Re: [CRYPTO] inconsistent naming CryptoRandomFactory.getCryptoRandom : CryptoCipherFactory.getInstance

On 30 June 2016 at 00:53, sebb wrote: > As the subject says; the two factories use a different naming convention. > > Would it be sensible to standardise on getInstance, given that the > class name says what the instance will be? Hm, but CryptoRandomFactory.getCryptoRandom()

Re: [CRYPTO] inconsistent naming CryptoRandomFactory.getCryptoRandom : CryptoCipherFactory.getInstance

Would it make sense to move the factory method to the base class? CryptoRandom random = CryptoRandom.getInstance(); Emmanuel Bourg - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands,

Re: [CRYPTO] inconsistent naming CryptoRandomFactory.getCryptoRandom : CryptoCipherFactory.getInstance

On 30 June 2016 at 11:01, Stian Soiland-Reyes wrote: > On 30 June 2016 at 00:53, sebb wrote: >> As the subject says; the two factories use a different naming convention. >> >> Would it be sensible to standardise on getInstance, given that the >> class name

Re: [CRYPTO] inconsistent naming CryptoRandomFactory.getCryptoRandom : CryptoCipherFactory.getInstance

On 30 June 2016 at 12:37, Benedikt Ritter wrote: > sebb schrieb am Do., 30. Juni 2016 um 13:16 Uhr: > >> On 30 June 2016 at 11:01, Stian Soiland-Reyes wrote: >> > On 30 June 2016 at 00:53, sebb wrote: >> >> As the

Re: [Fileupload] CVE security page and site distribution

We still need to create a security site. Commons Compress can be used as an example for this. I don't have time to do it right now. Benedikt Benedikt Ritter schrieb am Do., 30. Juni 2016 um 12:41 Uhr: > Hello Bernd, > > I've fixed this in revision 14202 in the dist area.

Re: [CRYPTO] inconsistent naming CryptoRandomFactory.getCryptoRandom : CryptoCipherFactory.getInstance

sebb schrieb am Do., 30. Juni 2016 um 13:16 Uhr: > On 30 June 2016 at 11:01, Stian Soiland-Reyes wrote: > > On 30 June 2016 at 00:53, sebb wrote: > >> As the subject says; the two factories use a different naming > convention. > >> > >>

Re: [CRYPTO] inconsistent naming CryptoRandomFactory.getCryptoRandom : CryptoCipherFactory.getInstance

On 30 June 2016 at 12:15, sebb wrote: > It would also allow the following usage: > import static > org.apache.commons.crypto.random.CryptoRandomFactory.getCryptoRandom; > CryptoRandom random = getCryptoRandom(properties); I didn't consider static import. You've won me over,

Re: [2/2] commons-crypto git commit: try-with-resources.

Agree for readability (and any future stack traces) that .close() should be explicit in the one test case that actually test an early close() doesn't fail :) On 30 June 2016 at 01:22, Gary Gregory wrote: > I disagree with the -1s, but hey, that's just me -1. Reverted. > >

Re: [crypto] Camel case for names

Sun, Dapeng schrieb am Do., 30. Juni 2016 um 07:32 Uhr: > +1 for keeping them consistent. > > I prefer "OpenSslCipher" > +1 for this as well. I don't like upper case abbreviations in class names. Benedikt > > Regards > Dapeng > > -Original Message- > From: Gary

Re: svn commit: r1750760 - in /commons/proper/io/trunk/src: changes/ main/java/org/apache/commons/io/input/ test/java/org/apache/commons/io/input/

Hi Jochen, wouldn't it be good to have a Jira issue for this change? Regards, Benedikt schrieb am Do., 30. Juni 2016 um 11:04: > Author: jochen > Date: Thu Jun 30 09:04:21 2016 > New Revision: 1750760 > > URL: http://svn.apache.org/viewvc?rev=1750760=rev > Log: > Added the

Re: [CRYPTO] inconsistent naming CryptoRandomFactory.getCryptoRandom : CryptoCipherFactory.getInstance

On 30 June 2016 at 13:59, Emmanuel Bourg wrote: > Would it make sense to move the factory method to the base class? > >CryptoRandom random = CryptoRandom.getInstance(); It's an interface, not a base class. > Emmanuel Bourg > > >

Re: [CRYPTO] inconsistent naming CryptoRandomFactory.getCryptoRandom : CryptoCipherFactory.getInstance

If you were using Java 8, you could totally have the factory in the interface now. On 30 June 2016 at 10:12, sebb wrote: > On 30 June 2016 at 13:59, Emmanuel Bourg wrote: > > Would it make sense to move the factory method to the base class? > > > >

Re: [DISCUSS] "Fraction" also in Commons Lang (Was: [VOTE] New component: Rational numbers)

I’m going to have a go at the implementation here. I figure we can talk more about it after we have a proposed solution in place. -Rob > On Jun 28, 2016, at 7:29 AM, Gilles wrote: > > On Tue, 28 Jun 2016 07:05:25 -0400, Matt Adereth wrote: >> Fraction in o.a.c.m.

[CRYPTO] is the ConfigurationKeys class needed?

The entries in ConfigurationKeys are only usable with one of the factories. It might therefore be more sensible to define them in the relevant factory classes. This would also allow the names to be shortened. For example, ConfigurationKeys.SECURE_RANDOM_CLASSES_KEY could become

[crypto] examples in the production code

Hi, It seems to me that org.apache.commons.crypto.examples does not belong in the main tree. Gary -- E-Mail: garydgreg...@gmail.com | ggreg...@apache.org Java Persistence with Hibernate, Second Edition JUnit in Action, Second Edition

Re: [crypto] examples in the production code

This was done to ensure that the code actually worked; the original snippets in the user guide did not work. The source xref is now referenced from the user guide which ensures that the code is valid. This seemed like the best way to do this. The examples package can always be excluded from the

Re: [crypto] Camel case for names

All done in Git master. Gary On Thu, Jun 30, 2016 at 4:51 AM, Emmanuel Bourg wrote: > Le 30/06/2016 à 11:51, Stian Soiland-Reyes a écrit : > > > +1 OpenSSLCipher > > +1 as well > > Emmanuel Bourg > > > - >

Re: [crypto] Camel case for names

On 30 June 2016 at 17:36, Gary Gregory wrote: > All done in Git master. And what a mess it makes in Git messages when a file is renamed ... it's very difficult to follow the changes on the mailing list. > Gary > > On Thu, Jun 30, 2016 at 4:51 AM, Emmanuel Bourg

Re: [crypto] examples in the production code

Why not just put them in the test tree. That feels more appropriate, at least to me. Gary On Jun 30, 2016 12:00 PM, "sebb" wrote: > This was done to ensure that the code actually worked; the original > snippets in the user guide did not work. > > The source xref is now

Re: [Fileupload] CVE security page and site distribution

Hello, I pushed a security report for commons fileupload (incl. the 3 CVEs I could find). http://svn.apache.org/viewvc?rev=1750857=rev Please somebody have a look and publish the site (I dont trust my tooling with this). After the push it needs to be linked from the commons-security page as

compressed method in Apache commens VFS 2.1

Hi All, I'm Thushanthan following computer science at university of Jaffna,Srilanka.i found some issues while creating API. In the Apache commens VFS 2.1 there are many packages,classes and methods. within the methods i found there was no methods for compressed and decompressed the file.So i like

Re: compressed method in Apache commens VFS 2.1

Hello Thushanthan, Amalanathan Thushanthan schrieb am Fr., 1. Juli 2016 um 01:59 Uhr: > Hi All, > > I'm Thushanthan following computer science at university of > Jaffna,Srilanka.i found some issues while creating API. In the Apache > commens VFS 2.1 there are many

Re: [crypto] examples in the production code

Gary Gregory schrieb am Do., 30. Juni 2016 um 22:22 Uhr: > Why not just put them in the test tree. That feels more appropriate, at > least to me. > +1 > > Gary > On Jun 30, 2016 12:00 PM, "sebb" wrote: > > > This was done to ensure that the code