[jira] [Commented] (CODEC-96) Base64 encode() method is no longer thread-safe, breaking clients using it as a shared BinaryEncoder
[
https://issues.apache.org/jira/browse/CODEC-96?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13243740#comment-13243740
]
Gary D. Gregory commented on CODEC-96:
--
The patch CODEX-96-2.patch applies cleanly on trunk but the
codec-96-3rd-attempt.patch does not.
What is what here?
Can someone provide a roadmap, a definitive patch, or just do it?
I'd like to push an RC and this seems like the last important issue. I am happy
to skip it until 1.8 of course.
Thank you,
Gary
Base64 encode() method is no longer thread-safe, breaking clients using it as
a shared BinaryEncoder
Key: CODEC-96
URL: https://issues.apache.org/jira/browse/CODEC-96
Project: Commons Codec
Issue Type: Bug
Affects Versions: 1.4
Reporter: Matt Ryall
Assignee: Julius Davies
Fix For: 1.x
Attachments: CODEC-96.patch, CODEX-96-2.patch,
codec-96-3rd-attempt.patch
Streaming support was added to Base64 in commons-codec 1.4 with CODEC-69.
This introduced instance variables to Base64 which means the class can no
longer be used as a shared BinaryEncoder instance.
For example, BinaryEncoder has an interface which could be (and was) used
like this with Base64:
{code:java}
class Example {
private BinaryEncoder encoder = new Base64();
byte[] someMethod(byte[] data) {
try {
return encoder.encode(data);
}
catch (EncoderException e) {
throw new RuntimeException(e);
}
}
}
{code}
Base64 is no longer thread-safe in commons-codec 1.4, so code like the above
which is accessed by multiple threads can throw NullPointerException:
{noformat}
java.lang.NullPointerException
at org.apache.commons.codec.binary.Base64.encode(Base64.java:469)
at org.apache.commons.codec.binary.Base64.encode(Base64.java:937)
at ... (application code)
{noformat}
Looking at the implementation of Base64, I think making it thread-safe for
this kind of usage would be quite tricky. I haven't attempted to prepare a
patch.
I would be happy if it was indicated in the Javadoc that Base64 is not
thread-safe and should not be shared. However, some other users of
commons-codec might be more worried about this regression.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CODEC-96) Base64 encode() method is no longer thread-safe, breaking clients using it as a shared BinaryEncoder
[
https://issues.apache.org/jira/browse/CODEC-96?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13243742#comment-13243742
]
Sebb commented on CODEC-96:
---
codec-96-3rd-attempt.patch is very old (2010). I think it can be ignored.
CODEX-96-2.patch is the latest patch, but as already mentioned on the dev list
causes Clirr to report errors.
I think these are harmless, as they don't affect the public API as far as I can
tell, but I don't use Codec in earnest.
Base64 encode() method is no longer thread-safe, breaking clients using it as
a shared BinaryEncoder
Key: CODEC-96
URL: https://issues.apache.org/jira/browse/CODEC-96
Project: Commons Codec
Issue Type: Bug
Affects Versions: 1.4
Reporter: Matt Ryall
Assignee: Julius Davies
Fix For: 1.x
Attachments: CODEC-96.patch, CODEX-96-2.patch,
codec-96-3rd-attempt.patch
Streaming support was added to Base64 in commons-codec 1.4 with CODEC-69.
This introduced instance variables to Base64 which means the class can no
longer be used as a shared BinaryEncoder instance.
For example, BinaryEncoder has an interface which could be (and was) used
like this with Base64:
{code:java}
class Example {
private BinaryEncoder encoder = new Base64();
byte[] someMethod(byte[] data) {
try {
return encoder.encode(data);
}
catch (EncoderException e) {
throw new RuntimeException(e);
}
}
}
{code}
Base64 is no longer thread-safe in commons-codec 1.4, so code like the above
which is accessed by multiple threads can throw NullPointerException:
{noformat}
java.lang.NullPointerException
at org.apache.commons.codec.binary.Base64.encode(Base64.java:469)
at org.apache.commons.codec.binary.Base64.encode(Base64.java:937)
at ... (application code)
{noformat}
Looking at the implementation of Base64, I think making it thread-safe for
this kind of usage would be quite tricky. I haven't attempted to prepare a
patch.
I would be happy if it was indicated in the Javadoc that Base64 is not
thread-safe and should not be shared. However, some other users of
commons-codec might be more worried about this regression.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CODEC-133) Please add a function for the MD5/SHA1/SHA-512 based Unix crypt(3) hash variants
[ https://issues.apache.org/jira/browse/CODEC-133?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13243758#comment-13243758 ] Christian Hammers commented on CODEC-133: - A new approach: While playing around with the new Kotlin JVM language, I tried to convert the original C sources of MD5 and SHA2 crypt() to Kotlin and after this to Java just to see the differences. The nice benefit of this excersise is that we now have Java implementations that are not only better commented than the ones from UTexas but also sufficiently different to not have any copyright problems. Any resemblance is due to the fact that we both translated the same C code nearly line by line. So please accept the attached patch :-) Please add a function for the MD5/SHA1/SHA-512 based Unix crypt(3) hash variants Key: CODEC-133 URL: https://issues.apache.org/jira/browse/CODEC-133 Project: Commons Codec Issue Type: New Feature Affects Versions: 1.6 Reporter: Christian Hammers Labels: MD5, SHA-512, crypt(3), crypto, hash Attachments: crypt3-with-utexas-licence.diff The Linux libc6 crypt(3) function, which is used to generate e.g. the password hashes in /etc/shadow, is available in nearly all other programming languages (Perl, PHP, Python, C, C++, ...) and databases like MySQL and offers MD5/SHA1/SHA-512 based algorithms that were improved by adding a salt and several iterations to make rainbow table attacks harder. Thus they are widely used to store user passwords. Java, though, has due it's platform independence, no direct access to the libc functions and still lacks an proper port of the crypt(3) function. I already filed a wishlist bug (CODEC-104) for the traditional 56-bit DES based crypt(3) method but would also like to see the much stronger algorithms. There are other bug reports like DIRSTUDIO-738 that demand those crypt variants for some specific applications so there it would benefit other Apache projects as well. Java ports of most of the specific crypt variants are already existing, but they would have to be cleaned up, properly tested and license checked: ftp://ftp.arlut.utexas.edu/pub/java_hashes/ I would be willing to help here by cleaning the source code and writing unit tests etc. but I'd like to generally know if you are interested and if there's someone who can do a code review (it's security relevant after all and I'm no crypto guy) bye, -christian- -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CODEC-133) Please add a function for the MD5/SHA1/SHA-512 based Unix crypt(3) hash variants
[ https://issues.apache.org/jira/browse/CODEC-133?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Hammers updated CODEC-133: Attachment: commons-codec-crypt3.diff Adds GNU libc compatible crypt() methods. Md5Crypt and Sha2Crypt are almoste line-by-line translations of the original (Public Domain / Beerware) C code by me, UnixCrypt comes from another Apache project and was left almost untouched and the other files/testcases are from me. Please add a function for the MD5/SHA1/SHA-512 based Unix crypt(3) hash variants Key: CODEC-133 URL: https://issues.apache.org/jira/browse/CODEC-133 Project: Commons Codec Issue Type: New Feature Affects Versions: 1.6 Reporter: Christian Hammers Labels: MD5, SHA-512, crypt(3), crypto, hash Attachments: commons-codec-crypt3.diff, crypt3-with-utexas-licence.diff The Linux libc6 crypt(3) function, which is used to generate e.g. the password hashes in /etc/shadow, is available in nearly all other programming languages (Perl, PHP, Python, C, C++, ...) and databases like MySQL and offers MD5/SHA1/SHA-512 based algorithms that were improved by adding a salt and several iterations to make rainbow table attacks harder. Thus they are widely used to store user passwords. Java, though, has due it's platform independence, no direct access to the libc functions and still lacks an proper port of the crypt(3) function. I already filed a wishlist bug (CODEC-104) for the traditional 56-bit DES based crypt(3) method but would also like to see the much stronger algorithms. There are other bug reports like DIRSTUDIO-738 that demand those crypt variants for some specific applications so there it would benefit other Apache projects as well. Java ports of most of the specific crypt variants are already existing, but they would have to be cleaned up, properly tested and license checked: ftp://ftp.arlut.utexas.edu/pub/java_hashes/ I would be willing to help here by cleaning the source code and writing unit tests etc. but I'd like to generally know if you are interested and if there's someone who can do a code review (it's security relevant after all and I'm no crypto guy) bye, -christian- -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Issue Comment Edited] (CODEC-133) Please add a function for the MD5/SHA1/SHA-512 based Unix crypt(3) hash variants
[ https://issues.apache.org/jira/browse/CODEC-133?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13243758#comment-13243758 ] Christian Hammers edited comment on CODEC-133 at 4/1/12 4:02 PM: - A new approach: While playing around with the new Kotlin JVM language, I tried to convert the original C sources of MD5 and SHA2 crypt() to Kotlin and after this to Java just to see the differences. The nice benefit of this excersise is that we now have Java implementations that are not only better commented than the ones from UTexas but also sufficiently different to not have any copyright problems. Any resemblance is due to the fact that we both translated the same C code nearly line by line. So please accept the attached patch commons-codec-crypt3.diff! :-) was (Author: lathspell): A new approach: While playing around with the new Kotlin JVM language, I tried to convert the original C sources of MD5 and SHA2 crypt() to Kotlin and after this to Java just to see the differences. The nice benefit of this excersise is that we now have Java implementations that are not only better commented than the ones from UTexas but also sufficiently different to not have any copyright problems. Any resemblance is due to the fact that we both translated the same C code nearly line by line. So please accept the attached patch :-) Please add a function for the MD5/SHA1/SHA-512 based Unix crypt(3) hash variants Key: CODEC-133 URL: https://issues.apache.org/jira/browse/CODEC-133 Project: Commons Codec Issue Type: New Feature Affects Versions: 1.6 Reporter: Christian Hammers Labels: MD5, SHA-512, crypt(3), crypto, hash Attachments: commons-codec-crypt3.diff, crypt3-with-utexas-licence.diff The Linux libc6 crypt(3) function, which is used to generate e.g. the password hashes in /etc/shadow, is available in nearly all other programming languages (Perl, PHP, Python, C, C++, ...) and databases like MySQL and offers MD5/SHA1/SHA-512 based algorithms that were improved by adding a salt and several iterations to make rainbow table attacks harder. Thus they are widely used to store user passwords. Java, though, has due it's platform independence, no direct access to the libc functions and still lacks an proper port of the crypt(3) function. I already filed a wishlist bug (CODEC-104) for the traditional 56-bit DES based crypt(3) method but would also like to see the much stronger algorithms. There are other bug reports like DIRSTUDIO-738 that demand those crypt variants for some specific applications so there it would benefit other Apache projects as well. Java ports of most of the specific crypt variants are already existing, but they would have to be cleaned up, properly tested and license checked: ftp://ftp.arlut.utexas.edu/pub/java_hashes/ I would be willing to help here by cleaning the source code and writing unit tests etc. but I'd like to generally know if you are interested and if there's someone who can do a code review (it's security relevant after all and I'm no crypto guy) bye, -christian- -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (JCS-89) UDP Discovery fails to report correct IP address to peers for back-connect when InetAddress.getLocalHost() fails to return an externally-visible address (i.e. returns a loca
[ https://issues.apache.org/jira/browse/JCS-89?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Vandahl resolved JCS-89. --- Resolution: Fixed Fix Version/s: jcs-1.4-dev Patch applied. UDP Discovery fails to report correct IP address to peers for back-connect when InetAddress.getLocalHost() fails to return an externally-visible address (i.e. returns a local address) --- Key: JCS-89 URL: https://issues.apache.org/jira/browse/JCS-89 Project: Commons JCS Issue Type: Bug Reporter: Diego Rivera Assignee: Thomas Vandahl Fix For: jcs-1.4-dev Attachments: jcs-89-fix.patch Original Estimate: 1h Remaining Estimate: 1h On certain environments where reverse-lookup of the machine's IP address isn't available, or other IP configurations restrict the ability of the JVM to determine its own canonical local address, it's impossible to determine ahead of time what address should be sent into the UDP multicast in order for lateral peers to establish the back-connection. The fix for this is simple: when the packet is received with the discovery message, determine the source host address of the packet that was received and set that to the discovery message's host property (setHost(packet.getAddress().getHostAddress()). This way, it's 100% for certain we'll be back-connecting to the correct instance. A patch will be uploaded shortly. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (MATH-773) You should be able to run evolution simulation for a certain amount of time.
[ https://issues.apache.org/jira/browse/MATH-773?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Neidhart updated MATH-773: - Fix Version/s: 3.1 You should be able to run evolution simulation for a certain amount of time. Key: MATH-773 URL: https://issues.apache.org/jira/browse/MATH-773 Project: Commons Math Issue Type: Improvement Reporter: Reid Hochstedler Labels: genetics Fix For: 3.1 Attachments: MATH-773.r2.txt, MATH-773.txt Original Estimate: 2h Remaining Estimate: 2h You should be able to run your GeneticAlgorithm for a fixed amount of time. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MATH-773) You should be able to run evolution simulation for a certain amount of time.
[ https://issues.apache.org/jira/browse/MATH-773?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13243779#comment-13243779 ] Thomas Neidhart commented on MATH-773: -- The patch has been added in r1308151. Apart from some minor corrections and javadoc fixes, the name has been changed to FixedElapsedTime. Thanks for your contribution! You should be able to run evolution simulation for a certain amount of time. Key: MATH-773 URL: https://issues.apache.org/jira/browse/MATH-773 Project: Commons Math Issue Type: Improvement Reporter: Reid Hochstedler Labels: genetics Fix For: 3.1 Attachments: MATH-773.r2.txt, MATH-773.txt Original Estimate: 2h Remaining Estimate: 2h You should be able to run your GeneticAlgorithm for a fixed amount of time. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (MATH-767) Unbalanced code usage in javadoc
[
https://issues.apache.org/jira/browse/MATH-767?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Neidhart resolved MATH-767.
--
Resolution: Fixed
Unbalanced code usage in javadoc
--
Key: MATH-767
URL: https://issues.apache.org/jira/browse/MATH-767
Project: Commons Math
Issue Type: Improvement
Affects Versions: 3.0
Environment: n/a
Reporter: Dennis Hendriks
Labels: javadoc
Fix For: 3.1
See http://commons.apache.org/math/apidocs/index-all.html and scroll to the
section 'D'. Observe how in method discardMostRecentElements(int) in class
org.apache.commons.math3.util.ResizableDoubleArray, the style changes to
larger font. As we can see in the source code for that method:
{code}
* Discards the codeicode last elements of the array. For example,
{code}
this should become:
{code}
* Discards the codei/code last elements of the array. For example,
{code}
as then the code.../code is balanced. Or even better, it could become:
{code}
* Discards the {@code i} last elements of the array. For example,
{code}
This applies elsewhere as well, for instance the isSame(Chromosome) method in
the org.apache.commons.math3.genetics.BinaryChromosome class.
We should probably check all javadoc, to make sure this is correct
everywhere. Since it is way too much to do manually, maybe a script or other
automated check could detect such cases?
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MATH-767) Unbalanced code usage in javadoc
[
https://issues.apache.org/jira/browse/MATH-767?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13243794#comment-13243794
]
Thomas Neidhart commented on MATH-767:
--
Thanks for reporting it.
I have searched the code base for other occurrences of this problem using this
regexp:
{noformat}
find -name *.java -exec grep -H -e code[^/]*code {} \;
{noformat}
Fix for the remaining files has been done in r1308162.
Unbalanced code usage in javadoc
--
Key: MATH-767
URL: https://issues.apache.org/jira/browse/MATH-767
Project: Commons Math
Issue Type: Improvement
Affects Versions: 3.0
Environment: n/a
Reporter: Dennis Hendriks
Labels: javadoc
Fix For: 3.1
See http://commons.apache.org/math/apidocs/index-all.html and scroll to the
section 'D'. Observe how in method discardMostRecentElements(int) in class
org.apache.commons.math3.util.ResizableDoubleArray, the style changes to
larger font. As we can see in the source code for that method:
{code}
* Discards the codeicode last elements of the array. For example,
{code}
this should become:
{code}
* Discards the codei/code last elements of the array. For example,
{code}
as then the code.../code is balanced. Or even better, it could become:
{code}
* Discards the {@code i} last elements of the array. For example,
{code}
This applies elsewhere as well, for instance the isSame(Chromosome) method in
the org.apache.commons.math3.genetics.BinaryChromosome class.
We should probably check all javadoc, to make sure this is correct
everywhere. Since it is way too much to do manually, maybe a script or other
automated check could detect such cases?
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (MATH-767) Unbalanced code usage in javadoc
[
https://issues.apache.org/jira/browse/MATH-767?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Neidhart updated MATH-767:
-
Fix Version/s: 3.1
Unbalanced code usage in javadoc
--
Key: MATH-767
URL: https://issues.apache.org/jira/browse/MATH-767
Project: Commons Math
Issue Type: Improvement
Affects Versions: 3.0
Environment: n/a
Reporter: Dennis Hendriks
Labels: javadoc
Fix For: 3.1
See http://commons.apache.org/math/apidocs/index-all.html and scroll to the
section 'D'. Observe how in method discardMostRecentElements(int) in class
org.apache.commons.math3.util.ResizableDoubleArray, the style changes to
larger font. As we can see in the source code for that method:
{code}
* Discards the codeicode last elements of the array. For example,
{code}
this should become:
{code}
* Discards the codei/code last elements of the array. For example,
{code}
as then the code.../code is balanced. Or even better, it could become:
{code}
* Discards the {@code i} last elements of the array. For example,
{code}
This applies elsewhere as well, for instance the isSame(Chromosome) method in
the org.apache.commons.math3.genetics.BinaryChromosome class.
We should probably check all javadoc, to make sure this is correct
everywhere. Since it is way too much to do manually, maybe a script or other
automated check could detect such cases?
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
