[jira] [Commented] (CODEC-121) QuotedPrintableCodec does not support soft line break per the 'quoted-printable' example on Wikipedia
[
https://issues.apache.org/jira/browse/CODEC-121?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=1303#comment-1303
]
Thomas Neidhart commented on CODEC-121:
---
Hi Gary,
the latest commit to codec was 1296456, and the patch was created from 1296812
(using svn diff files > patch).
When I apply the patch myself (patch -p0 < patch), I get the following message:
{noformat}
patching file
src/main/java/org/apache/commons/codec/net/QuotedPrintableCodec.java
Hunk #1 succeeded at 42 with fuzz 1.
patching file
src/test/java/org/apache/commons/codec/net/QuotedPrintableCodecTest.java
{noformat}
The result is ok. The revision number will continue to increase even if there
are no commits to codec, or am I doing something wrong?
> QuotedPrintableCodec does not support soft line break per the
> 'quoted-printable' example on Wikipedia
> -
>
> Key: CODEC-121
> URL: https://issues.apache.org/jira/browse/CODEC-121
> Project: Commons Codec
> Issue Type: Bug
>Affects Versions: 1.5
> Environment: I tested on Windows 7.
>Reporter: Java John
> Labels: codec, decode, quoted-printable
> Fix For: 1.x
>
> Attachments: CODEC-121.patch
>
>
> Writing a unit test I discovered that the example Wikipedia uses for
> quoted-printable data does not decode but instead throws an exception.
> Their example is here: http://en.wikipedia.org/wiki/Quoted-printable#Example
> test:
> String qpdata = "If you believe that truth=3Dbeauty, then surely=20=\r\n"
> +
> "mathematics is the most beautiful branch of philosophy.";
> String expected = "If you believe that truth=beauty, then surely " +
> "mathematics is the most beautiful branch of philosophy.";
> assertEquals( expected, new QuotedPrintableCodec().decode(qpdata) );
> I suppose I could fix if you like but currently I'm not a registered
> developer.
--
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] (CHAIN-67) Refactor of explicit Exception throws to a RuntimeException type
[
https://issues.apache.org/jira/browse/CHAIN-67?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=1301#comment-1301
]
Simone Tripodi commented on CHAIN-67:
-
Patch looks more than good, I am going to apply it, thanks!
> Refactor of explicit Exception throws to a RuntimeException type
>
>
> Key: CHAIN-67
> URL: https://issues.apache.org/jira/browse/CHAIN-67
> Project: Commons Chain
> Issue Type: Improvement
>Affects Versions: 2.0
>Reporter: Elijah Zupancic
>Priority: Minor
> Labels: exception-handling
> Fix For: 2.0
>
> Attachments: chain-67.diff
>
> Original Estimate: 2h
> Remaining Estimate: 2h
>
> As I've been working on the examples and the documentation for v2 of
> chain, I've noticed that the API for exception handling of Command and
> Chain is clunky.
> When executing a command like:
> {code:java}
>ProfileContext context = new ProfileContext();
>Command command = new ProfileCheck();
>try {
>command.execute(context);
>}
>catch (Exception e) {
>throw new RuntimeException(e);
>}
> {code}
> The user of chain has to explicitly catch Exception. If the desire was
> to catch the most base error and force the user to deal with it, why
> aren't we using Throwable? Anyways, this design leads to less than
> elegant code and since we will be breaking the API in v2, I would like
> to suggest a different approach.
> I suggest that Command and Chain should throw a custom exception class
> called ChainException that inherits from RuntimeException. And in the
> CommandBase, ChainBase we wrap the catch of Exception in this runtime
> exception. Moreover, we would attach to ChainException some optional
> debug information about the Context invoked when the exception was
> encountered.
--
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] (SANSELAN-65) TiffReader throws Can't find Rows per strip in case rows per strip is not present
[ https://issues.apache.org/jira/browse/SANSELAN-65?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Piyush Kapoor updated SANSELAN-65: -- Attachment: TiffReader.java.patch Granting Licence to ASF for inclusion > TiffReader throws Can't find Rows per strip in case rows per strip is not > present > - > > Key: SANSELAN-65 > URL: https://issues.apache.org/jira/browse/SANSELAN-65 > Project: Commons Sanselan > Issue Type: Bug > Components: Format: TIFF > Environment: Windows - 7 64 bit >Reporter: Piyush Kapoor >Priority: Critical > Labels: patch > Attachments: TiffReader.java.patch, TiffReader.java.patch > > Original Estimate: 1m > Remaining Estimate: 1m > > If a TIFF file doesnot contain a tag TIFF_TAG_ROWS_PER_STRIP then TIFFReader > thwos an exception . So we don't get buffered image for that tiff . > Fix is :- According to Tiff Specification if rows per strip is not present , > then we can assume entire image as one strip . > So in this case Rows per Strip = Image_length . > I tried this and image worked . > Read the following tag :- > http://www.awaresystems.be/imaging/tiff/tifftags/rowsperstrip.html -- 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] (CONFIGURATION-482) Optional dependencies are not marked optional in the manifest's Import-Package section
[ https://issues.apache.org/jira/browse/CONFIGURATION-482?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13222182#comment-13222182 ] Chris Seieroe commented on CONFIGURATION-482: - Looks like it already does as of version 2.3.4. If I'm reading the pom files correctly, commons-config 1.8 uses version 2.3.5. At least that's what I see in commons-parent version 23. http://issues.apache.org/jira/browse/FELIX-954 http://issues.apache.org/jira/browse/FELIX-2809 > Optional dependencies are not marked optional in the manifest's > Import-Package section > -- > > Key: CONFIGURATION-482 > URL: https://issues.apache.org/jira/browse/CONFIGURATION-482 > Project: Commons Configuration > Issue Type: Bug > Components: Build >Affects Versions: 1.8 >Reporter: Chris Seieroe >Priority: Minor > > The following page lists the runtime dependencies based on the components. > This is reflected in the pom file since many are listed as optional (e.g. > commons-jexl). However, if you want to use commons-configuration in an OSGi > container, those become required because the corresponding packages are > listed in the manifest's Import-Package section. They do not have the > "resolution:=optional" qualifier on it so you get an error if you do not > include something like commons-jexl yourself. > http://commons.apache.org/configuration/dependencies.html -- 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-134) Base32 would decode some invalid Base32 encoded string into arbitrary value
[ https://issues.apache.org/jira/browse/CODEC-134?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hanson Char updated CODEC-134: -- Attachment: (was: patch.txt) > Base32 would decode some invalid Base32 encoded string into arbitrary value > --- > > Key: CODEC-134 > URL: https://issues.apache.org/jira/browse/CODEC-134 > Project: Commons Codec > Issue Type: Bug >Affects Versions: 1.6 > Environment: All >Reporter: Hanson Char > Labels: security > Attachments: diff-120304-22.txt > > > Example, there is no byte array value that can be encoded into the string > "C5CYMIHWQUUZMKUGZHGEOSJSQDE4L===", but the existing Base32 implementation > would not reject it but decode it into an arbitrary value which if re-encoded > again using the same implementation would result in the string > "C5CYMIHWQUUZMKUGZHGEOSJSQDE4K===". > Instead of blindly decoding the invalid string, the Base32 codec should > reject it (eg by throwing IlleglArgumentException) to avoid security > exploitation (such as tunneling additional information via seemingly valid > base 32 strings). -- 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-134) Base32 would decode some invalid Base32 encoded string into arbitrary value
[ https://issues.apache.org/jira/browse/CODEC-134?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hanson Char updated CODEC-134: -- Attachment: (was: diff-120304-20.txt) > Base32 would decode some invalid Base32 encoded string into arbitrary value > --- > > Key: CODEC-134 > URL: https://issues.apache.org/jira/browse/CODEC-134 > Project: Commons Codec > Issue Type: Bug >Affects Versions: 1.6 > Environment: All >Reporter: Hanson Char > Labels: security > Attachments: diff-120304-22.txt, patch.txt > > > Example, there is no byte array value that can be encoded into the string > "C5CYMIHWQUUZMKUGZHGEOSJSQDE4L===", but the existing Base32 implementation > would not reject it but decode it into an arbitrary value which if re-encoded > again using the same implementation would result in the string > "C5CYMIHWQUUZMKUGZHGEOSJSQDE4K===". > Instead of blindly decoding the invalid string, the Base32 codec should > reject it (eg by throwing IlleglArgumentException) to avoid security > exploitation (such as tunneling additional information via seemingly valid > base 32 strings). -- 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-134) Base32 would decode some invalid Base32 encoded string into arbitrary value
[ https://issues.apache.org/jira/browse/CODEC-134?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13222179#comment-13222179 ] Hanson Char commented on CODEC-134: --- I've just uploaded the latest patch, diff-120304-22.txt, superseding all previous patches. This patch passed all the unit tests via "mvn test". > Base32 would decode some invalid Base32 encoded string into arbitrary value > --- > > Key: CODEC-134 > URL: https://issues.apache.org/jira/browse/CODEC-134 > Project: Commons Codec > Issue Type: Bug >Affects Versions: 1.6 > Environment: All >Reporter: Hanson Char > Labels: security > Attachments: diff-120304-22.txt, patch.txt > > > Example, there is no byte array value that can be encoded into the string > "C5CYMIHWQUUZMKUGZHGEOSJSQDE4L===", but the existing Base32 implementation > would not reject it but decode it into an arbitrary value which if re-encoded > again using the same implementation would result in the string > "C5CYMIHWQUUZMKUGZHGEOSJSQDE4K===". > Instead of blindly decoding the invalid string, the Base32 codec should > reject it (eg by throwing IlleglArgumentException) to avoid security > exploitation (such as tunneling additional information via seemingly valid > base 32 strings). -- 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-134) Base32 would decode some invalid Base32 encoded string into arbitrary value
[ https://issues.apache.org/jira/browse/CODEC-134?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hanson Char updated CODEC-134: -- Attachment: diff-120304-22.txt > Base32 would decode some invalid Base32 encoded string into arbitrary value > --- > > Key: CODEC-134 > URL: https://issues.apache.org/jira/browse/CODEC-134 > Project: Commons Codec > Issue Type: Bug >Affects Versions: 1.6 > Environment: All >Reporter: Hanson Char > Labels: security > Attachments: diff-120304-20.txt, diff-120304-22.txt, patch.txt > > > Example, there is no byte array value that can be encoded into the string > "C5CYMIHWQUUZMKUGZHGEOSJSQDE4L===", but the existing Base32 implementation > would not reject it but decode it into an arbitrary value which if re-encoded > again using the same implementation would result in the string > "C5CYMIHWQUUZMKUGZHGEOSJSQDE4K===". > Instead of blindly decoding the invalid string, the Base32 codec should > reject it (eg by throwing IlleglArgumentException) to avoid security > exploitation (such as tunneling additional information via seemingly valid > base 32 strings). -- 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-134) Base32 would decode some invalid Base32 encoded string into arbitrary value
[ https://issues.apache.org/jira/browse/CODEC-134?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13222172#comment-13222172 ] Hanson Char commented on CODEC-134: --- Hi Gary, I am not sure I understand the meaning of the name "CODEC_101_MULTIPLE_OF_3". Does it mean a multiple of 3 in terms of the number of bits or bytes ? If it is bytes, both "123" and "124" contain 3 bytes. If it is the number of "1" in the UTF-8 bit array, the byte array of "123" contains 10 bits (on) whereas that of "124" contains 9 bits. In the only two test cases (in Base64InputStreamTest.java) where CODEC_101_MULTIPLE_OF_3 is used, CODEC_101_MULTIPLE_OF_3 appears to be used simply as a straight base 64 encoded string that the test case attempt to decode (via a Base64InputStream). Since the "123" cannot be a possible base 64 encoded value, the two test cases should fail rather than pass. What am I missing ? Regards, Hanson > Base32 would decode some invalid Base32 encoded string into arbitrary value > --- > > Key: CODEC-134 > URL: https://issues.apache.org/jira/browse/CODEC-134 > Project: Commons Codec > Issue Type: Bug >Affects Versions: 1.6 > Environment: All >Reporter: Hanson Char > Labels: security > Attachments: diff-120304-20.txt, patch.txt > > > Example, there is no byte array value that can be encoded into the string > "C5CYMIHWQUUZMKUGZHGEOSJSQDE4L===", but the existing Base32 implementation > would not reject it but decode it into an arbitrary value which if re-encoded > again using the same implementation would result in the string > "C5CYMIHWQUUZMKUGZHGEOSJSQDE4K===". > Instead of blindly decoding the invalid string, the Base32 codec should > reject it (eg by throwing IlleglArgumentException) to avoid security > exploitation (such as tunneling additional information via seemingly valid > base 32 strings). -- 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-134) Base32 would decode some invalid Base32 encoded string into arbitrary value
[ https://issues.apache.org/jira/browse/CODEC-134?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13222167#comment-13222167 ] Gary D. Gregory commented on CODEC-134: --- Hi Hanson, At first glance, changing CODEC_101_MULTIPLE_OF_3 to a value that is NOT a multiple of three does not "smell" right. Can you find a way to test this without making the constant name "lie"? After all CODEC_101_MULTIPLE_OF_3 must be a multiple of three for a good reason! ;) There > Base32 would decode some invalid Base32 encoded string into arbitrary value > --- > > Key: CODEC-134 > URL: https://issues.apache.org/jira/browse/CODEC-134 > Project: Commons Codec > Issue Type: Bug >Affects Versions: 1.6 > Environment: All >Reporter: Hanson Char > Labels: security > Attachments: diff-120304-20.txt, patch.txt > > > Example, there is no byte array value that can be encoded into the string > "C5CYMIHWQUUZMKUGZHGEOSJSQDE4L===", but the existing Base32 implementation > would not reject it but decode it into an arbitrary value which if re-encoded > again using the same implementation would result in the string > "C5CYMIHWQUUZMKUGZHGEOSJSQDE4K===". > Instead of blindly decoding the invalid string, the Base32 codec should > reject it (eg by throwing IlleglArgumentException) to avoid security > exploitation (such as tunneling additional information via seemingly valid > base 32 strings). -- 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-134) Base32 would decode some invalid Base32 encoded string into arbitrary value
[ https://issues.apache.org/jira/browse/CODEC-134?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13222165#comment-13222165 ] Hanson Char commented on CODEC-134: --- Hi Gary, Please find attached diff-120304-20.txt for the unit tests. Note that I've also modified the value of Base64TestData#CODEC_101_MULTIPLE_OF_3 from "123" to "124", as "123" turns out to be an impossible base64 encoded value with "3" being the last character. Regards, Hanson > Base32 would decode some invalid Base32 encoded string into arbitrary value > --- > > Key: CODEC-134 > URL: https://issues.apache.org/jira/browse/CODEC-134 > Project: Commons Codec > Issue Type: Bug >Affects Versions: 1.6 > Environment: All >Reporter: Hanson Char > Labels: security > Attachments: diff-120304-20.txt, patch.txt > > > Example, there is no byte array value that can be encoded into the string > "C5CYMIHWQUUZMKUGZHGEOSJSQDE4L===", but the existing Base32 implementation > would not reject it but decode it into an arbitrary value which if re-encoded > again using the same implementation would result in the string > "C5CYMIHWQUUZMKUGZHGEOSJSQDE4K===". > Instead of blindly decoding the invalid string, the Base32 codec should > reject it (eg by throwing IlleglArgumentException) to avoid security > exploitation (such as tunneling additional information via seemingly valid > base 32 strings). -- 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-134) Base32 would decode some invalid Base32 encoded string into arbitrary value
[ https://issues.apache.org/jira/browse/CODEC-134?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hanson Char updated CODEC-134: -- Attachment: diff-120304-20.txt > Base32 would decode some invalid Base32 encoded string into arbitrary value > --- > > Key: CODEC-134 > URL: https://issues.apache.org/jira/browse/CODEC-134 > Project: Commons Codec > Issue Type: Bug >Affects Versions: 1.6 > Environment: All >Reporter: Hanson Char > Labels: security > Attachments: diff-120304-20.txt, patch.txt > > > Example, there is no byte array value that can be encoded into the string > "C5CYMIHWQUUZMKUGZHGEOSJSQDE4L===", but the existing Base32 implementation > would not reject it but decode it into an arbitrary value which if re-encoded > again using the same implementation would result in the string > "C5CYMIHWQUUZMKUGZHGEOSJSQDE4K===". > Instead of blindly decoding the invalid string, the Base32 codec should > reject it (eg by throwing IlleglArgumentException) to avoid security > exploitation (such as tunneling additional information via seemingly valid > base 32 strings). -- 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] (BEANUTILS-409) BeanUtils - 'describe' method returning Incorrect array value
[
https://issues.apache.org/jira/browse/BEANUTILS-409?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13222154#comment-13222154
]
Senthil Kumar Balakrishnan commented on BEANUTILS-409:
--
Hi Benny,
The Code is deliberately returning first value of the collection, though i
don't understand why it should. below is the code,
org.apache.commons.beanutils.converters.AbstractConverter.java
/**
* Return the first element from an Array (or Collection)
* or the value unchanged if not an Array (or Collection).
*
* N.B. This needs to be overriden for array/Collection converters.
*
* @param value The value to convert
* @return The first element in an Array (or Collection)
* or the value unchanged if not an Array (or Collection)
*/
protected Object convertArray(Object value) {
if (value == null) {
return null;
}
if (value.getClass().isArray()) {
if (Array.getLength(value) > 0) {
return Array.get(value, 0);
} else {
return null;
}
}
if (value instanceof Collection) {
Collection collection = (Collection)value;
if (collection.size() > 0) {
//Note: Looks like this is done deliberately.
return collection.iterator().next();
} else {
return null;
}
}
return value;
}
Thanks,
-Senthil Balakrishnan
> BeanUtils - 'describe' method returning Incorrect array value
> -
>
> Key: BEANUTILS-409
> URL: https://issues.apache.org/jira/browse/BEANUTILS-409
> Project: Commons BeanUtils
> Issue Type: Bug
>Affects Versions: 1.8.3
> Environment: commons-beanutils 1.8.3, jdk 1.6.0_20
>Reporter: benny
>Priority: Critical
> Labels: describe
>
> I want to convert a bean class to a map (key=the name of the member,value=the
> value of the member).
> I'm using the method BeanUtils.describe(beanClass);
> (I'm using commons-beanutils 1.8.3, jdk 1.6.0_20, on commons-beanutils 1.5 it
> works)
> The problem is that the return value is incorrect, (the map contain only the
> first item from the array),
> the code:
> public class Demo {
> private ArrayList myList = new ArrayList();
> public Demo() {
> myList.add("first_value");
> myList.add("second_value");
> }
>
> public ArrayList getMyList() {
> return myList;
> }
>
> public void setMyList(ArrayList myList) {
> this.myList = myList;
> }
>
> public static void main(String[] args) {
> Demo myBean = new Demo();
> try {
> Map describe = BeanUtils.describe(myBean);
> Iterator it = describe.entrySet().iterator();
> while (it.hasNext()) {
> Map.Entry pairs = (Map.Entry) it.next();
> System.out.println(String.format("key=%s,value=%s",
> (String) pairs.getKey(), (String) pairs.getValue()));
>
> }
> } catch (Exception e) {
> e.printStackTrace();
> }
> }
> }
> •The expected output:
>
> key=myList,value=[first_value,second_value]
> key=class,value=class $Demo
> •But the real output is:
>
> key=myList,value=[first_value]
> key=class,value=class $Demo
> As you can see the array contains two values but the output(and the map)
> contains only one,why??
--
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] (LANG-790) Null safe Navigation in ObjectUtils
[ https://issues.apache.org/jira/browse/LANG-790?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13222109#comment-13222109 ] Gokul Nanthakumar C commented on LANG-790: -- Hi Gary, I like JXPath, the issue is 1. we need to build JXPathContext for all the objects we want to navigate, not sure about the performance cost associated with that as well. 2. the developer should have idea about xpath to use this 3. by default JXPathContext.setLenient is false which will throw exception if the path is null or wrong 4. default value incase of null can not be specified explicitly, developer has to write if condition or use default value methods from other apis. I thought it will be very handy to have this method with default option and null safe navigation without knowledge of xpath. Please share your view. > Null safe Navigation in ObjectUtils > --- > > Key: LANG-790 > URL: https://issues.apache.org/jira/browse/LANG-790 > Project: Commons Lang > Issue Type: New Feature >Reporter: Gokul Nanthakumar C > > Adding a method for null safe navigation of objects will be very helpful. for > example a method like > ObjectUtils.getValue(Object obj, String "path", String defaultValue); > ex :ObjectUtils.getValue(myObject, "x.y.z", "default"); > it will navigate in the myObject like myObject.getX().getY().getZ(), if any > thing in the path is null (x,y or z), it will return the default value. > It will be really useful, it is like null safe navigation in groovy. -- 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-134) Base32 would decode some invalid Base32 encoded string into arbitrary value
[ https://issues.apache.org/jira/browse/CODEC-134?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13222101#comment-13222101 ] Gary D. Gregory commented on CODEC-134: --- Hi Hanson, Thank you for the patch. Can you provide unit tests with the patch? Thank you, Gary > Base32 would decode some invalid Base32 encoded string into arbitrary value > --- > > Key: CODEC-134 > URL: https://issues.apache.org/jira/browse/CODEC-134 > Project: Commons Codec > Issue Type: Bug >Affects Versions: 1.6 > Environment: All >Reporter: Hanson Char > Labels: security > Attachments: patch.txt > > > Example, there is no byte array value that can be encoded into the string > "C5CYMIHWQUUZMKUGZHGEOSJSQDE4L===", but the existing Base32 implementation > would not reject it but decode it into an arbitrary value which if re-encoded > again using the same implementation would result in the string > "C5CYMIHWQUUZMKUGZHGEOSJSQDE4K===". > Instead of blindly decoding the invalid string, the Base32 codec should > reject it (eg by throwing IlleglArgumentException) to avoid security > exploitation (such as tunneling additional information via seemingly valid > base 32 strings). -- 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-121) QuotedPrintableCodec does not support soft line break per the 'quoted-printable' example on Wikipedia
[ https://issues.apache.org/jira/browse/CODEC-121?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13222099#comment-13222099 ] Gary D. Gregory commented on CODEC-121: --- Hello Thomas, Thank you for the patch. Could you please create it against the latest from trunk please? I am getting errors applying the patch as it is. Gary > QuotedPrintableCodec does not support soft line break per the > 'quoted-printable' example on Wikipedia > - > > Key: CODEC-121 > URL: https://issues.apache.org/jira/browse/CODEC-121 > Project: Commons Codec > Issue Type: Bug >Affects Versions: 1.5 > Environment: I tested on Windows 7. >Reporter: Java John > Labels: codec, decode, quoted-printable > Fix For: 1.x > > Attachments: CODEC-121.patch > > > Writing a unit test I discovered that the example Wikipedia uses for > quoted-printable data does not decode but instead throws an exception. > Their example is here: http://en.wikipedia.org/wiki/Quoted-printable#Example > test: > String qpdata = "If you believe that truth=3Dbeauty, then surely=20=\r\n" > + > "mathematics is the most beautiful branch of philosophy."; > String expected = "If you believe that truth=beauty, then surely " + > "mathematics is the most beautiful branch of philosophy."; > assertEquals( expected, new QuotedPrintableCodec().decode(qpdata) ); > I suppose I could fix if you like but currently I'm not a registered > developer. -- 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-132) BeiderMorseEncoder OOM issues
[ https://issues.apache.org/jira/browse/CODEC-132?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13222097#comment-13222097 ] Gary D. Gregory commented on CODEC-132: --- Thank you for digging Thomas. Feel free to provide a patch :) with tests. It would be great if Matthew P. could comment here as well. Gary > BeiderMorseEncoder OOM issues > - > > Key: CODEC-132 > URL: https://issues.apache.org/jira/browse/CODEC-132 > Project: Commons Codec > Issue Type: Bug >Affects Versions: 1.6 >Reporter: Robert Muir > Attachments: CODEC-132_test.patch > > > In Lucene/Solr, we integrated this encoder into the latest release. > Our tests use a variety of random strings, and we have recent jenkins failures > from some input streams (of length <= 10), using huge amounts of memory (e.g. > > 64MB), > resulting in OOM. > I've created a test case (length is 30 here) that will OOM with -Xmx256M. > I haven't dug into this much as to what's causing it, but I suspect there > might be a bug > revolving around certain punctuation characters: we didn't see this happening > until > we beefed up our random string generation to start producing "html-like" > strings. -- 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-134) Base32 would decode some invalid Base32 encoded string into arbitrary value
[
https://issues.apache.org/jira/browse/CODEC-134?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hanson Char updated CODEC-134:
--
Comment: was deleted
(was: diff --git a/src/main/java/org/apache/commons/codec/binary/Base32.java
b/src/main/java/org/apache/commons/codec/binary/Base32.java
index a9da10f..9cd293b 100644
--- a/src/main/java/org/apache/commons/codec/binary/Base32.java
+++ b/src/main/java/org/apache/commons/codec/binary/Base32.java
@@ -274,7 +274,7 @@ public class Base32 extends BaseNCodec {
* @param inPos
*Position to start reading data from.
* @param inAvail
- *Amount of bytes available from input for encoding.
+ *Amount of bytes available from input for decoding.
*
* Output is written to {@link #buffer} as 8-bit octets, using {@link
#pos} as the buffer position
*/
@@ -320,30 +320,30 @@ public class Base32 extends BaseNCodec {
// we ignore partial bytes, i.e. only multiples of 8 count
switch (modulus) {
case 2 : // 10 bits, drop 2 and output one byte
-buffer[pos++] = (byte) ((bitWorkArea >> 2) & MASK_8BITS);
+buffer[pos++] = (byte) (dropBits(2) & MASK_8BITS);
break;
case 3 : // 15 bits, drop 7 and output 1 byte
-buffer[pos++] = (byte) ((bitWorkArea >> 7) & MASK_8BITS);
+buffer[pos++] = (byte) (dropBits(7) & MASK_8BITS);
break;
case 4 : // 20 bits = 2*8 + 4
-bitWorkArea = bitWorkArea >> 4; // drop 4 bits
+bitWorkArea = dropBits(4); // drop 4 bits
buffer[pos++] = (byte) ((bitWorkArea >> 8) & MASK_8BITS);
buffer[pos++] = (byte) ((bitWorkArea) & MASK_8BITS);
break;
case 5 : // 25bits = 3*8 + 1
-bitWorkArea = bitWorkArea >> 1;
+bitWorkArea = dropBits(1);
buffer[pos++] = (byte) ((bitWorkArea >> 16) & MASK_8BITS);
buffer[pos++] = (byte) ((bitWorkArea >> 8) & MASK_8BITS);
buffer[pos++] = (byte) ((bitWorkArea) & MASK_8BITS);
break;
case 6 : // 30bits = 3*8 + 6
-bitWorkArea = bitWorkArea >> 6;
+bitWorkArea = dropBits(6);
buffer[pos++] = (byte) ((bitWorkArea >> 16) & MASK_8BITS);
buffer[pos++] = (byte) ((bitWorkArea >> 8) & MASK_8BITS);
buffer[pos++] = (byte) ((bitWorkArea) & MASK_8BITS);
break;
case 7 : // 35 = 4*8 +3
-bitWorkArea = bitWorkArea >> 3;
+bitWorkArea = dropBits(3);
buffer[pos++] = (byte) ((bitWorkArea >> 24) & MASK_8BITS);
buffer[pos++] = (byte) ((bitWorkArea >> 16) & MASK_8BITS);
buffer[pos++] = (byte) ((bitWorkArea >> 8) & MASK_8BITS);
@@ -352,6 +352,28 @@ public class Base32 extends BaseNCodec {
}
}
}
+
+/**
+ *
+ * Drops the specified number of least significant bits from the
+ * {@link #bitWorkArea}.
+ *
+ *
+ * @param numBitsToDrop
+ *number of least significant bits to drop
+ *
+ * @return the value of {@link #bitWorkArea} after dropping the
+ *specified number of least significant bits
+ *
+ * @throws IllegalArgumentException
+ *if the bits being dropped contain any non-zero value
+ */
+private long dropBits(int numBitsToDrop) {
+if ((bitWorkArea & numBitsToDrop) != 0) {
+throw new IllegalArgumentException("Last encoded character (before
the paddings if any) is a valid base 32 alphabet but not a possible value");
+}
+return bitWorkArea >> numBitsToDrop;
+}
/**
*
diff --git a/src/main/java/org/apache/commons/codec/binary/Base64.java
b/src/main/java/org/apache/commons/codec/binary/Base64.java
index 1ee0eba..4261f88 100644
--- a/src/main/java/org/apache/commons/codec/binary/Base64.java
+++ b/src/main/java/org/apache/commons/codec/binary/Base64.java
@@ -410,7 +410,7 @@ public class Base64 extends BaseNCodec {
* @param inPos
*Position to start reading data from.
* @param inAvail
- *Amount of bytes available from input for encoding.
+ *Amount of bytes available from input for decoding.
*/
@Override
void decode(byte[] in, int inPos, int inAvail) {
@@ -455,17 +455,39 @@ public class Base64 extends BaseNCodec {
// case 1: // 6 bits - ignore entirely
// break;
case 2 : // 12 bits = 8 + 4
-bitWorkArea = bitWorkArea >> 4; // d
[jira] [Issue Comment Edited] (CODEC-134) Base32 would decode some invalid Base32 encoded string into arbitrary value
[ https://issues.apache.org/jira/browse/CODEC-134?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13222063#comment-13222063 ] Hanson Char edited comment on CODEC-134 at 3/4/12 11:47 PM: patch.txt attached was (Author: hchar): Sorry, should have attached the patch as a file. > Base32 would decode some invalid Base32 encoded string into arbitrary value > --- > > Key: CODEC-134 > URL: https://issues.apache.org/jira/browse/CODEC-134 > Project: Commons Codec > Issue Type: Bug >Affects Versions: 1.6 > Environment: All >Reporter: Hanson Char > Labels: security > Attachments: patch.txt > > > Example, there is no byte array value that can be encoded into the string > "C5CYMIHWQUUZMKUGZHGEOSJSQDE4L===", but the existing Base32 implementation > would not reject it but decode it into an arbitrary value which if re-encoded > again using the same implementation would result in the string > "C5CYMIHWQUUZMKUGZHGEOSJSQDE4K===". > Instead of blindly decoding the invalid string, the Base32 codec should > reject it (eg by throwing IlleglArgumentException) to avoid security > exploitation (such as tunneling additional information via seemingly valid > base 32 strings). -- 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-134) Base32 would decode some invalid Base32 encoded string into arbitrary value
[ https://issues.apache.org/jira/browse/CODEC-134?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hanson Char updated CODEC-134: -- Attachment: patch.txt Sorry, should have attached the patch as a file. > Base32 would decode some invalid Base32 encoded string into arbitrary value > --- > > Key: CODEC-134 > URL: https://issues.apache.org/jira/browse/CODEC-134 > Project: Commons Codec > Issue Type: Bug >Affects Versions: 1.6 > Environment: All >Reporter: Hanson Char > Labels: security > Attachments: patch.txt > > > Example, there is no byte array value that can be encoded into the string > "C5CYMIHWQUUZMKUGZHGEOSJSQDE4L===", but the existing Base32 implementation > would not reject it but decode it into an arbitrary value which if re-encoded > again using the same implementation would result in the string > "C5CYMIHWQUUZMKUGZHGEOSJSQDE4K===". > Instead of blindly decoding the invalid string, the Base32 codec should > reject it (eg by throwing IlleglArgumentException) to avoid security > exploitation (such as tunneling additional information via seemingly valid > base 32 strings). -- 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-134) Base32 would decode some invalid Base32 encoded string into arbitrary value
[
https://issues.apache.org/jira/browse/CODEC-134?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13222062#comment-13222062
]
Hanson Char commented on CODEC-134:
---
diff --git a/src/main/java/org/apache/commons/codec/binary/Base32.java
b/src/main/java/org/apache/commons/codec/binary/Base32.java
index a9da10f..9cd293b 100644
--- a/src/main/java/org/apache/commons/codec/binary/Base32.java
+++ b/src/main/java/org/apache/commons/codec/binary/Base32.java
@@ -274,7 +274,7 @@ public class Base32 extends BaseNCodec {
* @param inPos
*Position to start reading data from.
* @param inAvail
- *Amount of bytes available from input for encoding.
+ *Amount of bytes available from input for decoding.
*
* Output is written to {@link #buffer} as 8-bit octets, using {@link
#pos} as the buffer position
*/
@@ -320,30 +320,30 @@ public class Base32 extends BaseNCodec {
// we ignore partial bytes, i.e. only multiples of 8 count
switch (modulus) {
case 2 : // 10 bits, drop 2 and output one byte
-buffer[pos++] = (byte) ((bitWorkArea >> 2) & MASK_8BITS);
+buffer[pos++] = (byte) (dropBits(2) & MASK_8BITS);
break;
case 3 : // 15 bits, drop 7 and output 1 byte
-buffer[pos++] = (byte) ((bitWorkArea >> 7) & MASK_8BITS);
+buffer[pos++] = (byte) (dropBits(7) & MASK_8BITS);
break;
case 4 : // 20 bits = 2*8 + 4
-bitWorkArea = bitWorkArea >> 4; // drop 4 bits
+bitWorkArea = dropBits(4); // drop 4 bits
buffer[pos++] = (byte) ((bitWorkArea >> 8) & MASK_8BITS);
buffer[pos++] = (byte) ((bitWorkArea) & MASK_8BITS);
break;
case 5 : // 25bits = 3*8 + 1
-bitWorkArea = bitWorkArea >> 1;
+bitWorkArea = dropBits(1);
buffer[pos++] = (byte) ((bitWorkArea >> 16) & MASK_8BITS);
buffer[pos++] = (byte) ((bitWorkArea >> 8) & MASK_8BITS);
buffer[pos++] = (byte) ((bitWorkArea) & MASK_8BITS);
break;
case 6 : // 30bits = 3*8 + 6
-bitWorkArea = bitWorkArea >> 6;
+bitWorkArea = dropBits(6);
buffer[pos++] = (byte) ((bitWorkArea >> 16) & MASK_8BITS);
buffer[pos++] = (byte) ((bitWorkArea >> 8) & MASK_8BITS);
buffer[pos++] = (byte) ((bitWorkArea) & MASK_8BITS);
break;
case 7 : // 35 = 4*8 +3
-bitWorkArea = bitWorkArea >> 3;
+bitWorkArea = dropBits(3);
buffer[pos++] = (byte) ((bitWorkArea >> 24) & MASK_8BITS);
buffer[pos++] = (byte) ((bitWorkArea >> 16) & MASK_8BITS);
buffer[pos++] = (byte) ((bitWorkArea >> 8) & MASK_8BITS);
@@ -352,6 +352,28 @@ public class Base32 extends BaseNCodec {
}
}
}
+
+/**
+ *
+ * Drops the specified number of least significant bits from the
+ * {@link #bitWorkArea}.
+ *
+ *
+ * @param numBitsToDrop
+ *number of least significant bits to drop
+ *
+ * @return the value of {@link #bitWorkArea} after dropping the
+ *specified number of least significant bits
+ *
+ * @throws IllegalArgumentException
+ *if the bits being dropped contain any non-zero value
+ */
+private long dropBits(int numBitsToDrop) {
+if ((bitWorkArea & numBitsToDrop) != 0) {
+throw new IllegalArgumentException("Last encoded character (before
the paddings if any) is a valid base 32 alphabet but not a possible value");
+}
+return bitWorkArea >> numBitsToDrop;
+}
/**
*
diff --git a/src/main/java/org/apache/commons/codec/binary/Base64.java
b/src/main/java/org/apache/commons/codec/binary/Base64.java
index 1ee0eba..4261f88 100644
--- a/src/main/java/org/apache/commons/codec/binary/Base64.java
+++ b/src/main/java/org/apache/commons/codec/binary/Base64.java
@@ -410,7 +410,7 @@ public class Base64 extends BaseNCodec {
* @param inPos
*Position to start reading data from.
* @param inAvail
- *Amount of bytes available from input for encoding.
+ *Amount of bytes available from input for decoding.
*/
@Override
void decode(byte[] in, int inPos, int inAvail) {
@@ -455,17 +455,39 @@ public class Base64 extends BaseNCodec {
// case 1: // 6 bits - ignore entirely
// break;
case 2 : // 12 bits = 8 + 4
-bitWorkArea
[jira] [Created] (MATH-763) Recover source files that were not included in release 3.0
Recover source files that were not included in release 3.0
--
Key: MATH-763
URL: https://issues.apache.org/jira/browse/MATH-763
Project: Commons Math
Issue Type: Task
Reporter: Gilles
Priority: Trivial
Fix For: 3.1
Files
* BatteryNISTTest.java
* PivotingQRDecomposition.java
* PivotingQRDecompositionTest.java
* PivotingQRSolverTest.java
should be re-added to "trunk". They have been saved in the tag
{noformat}
https://svn.apache.org/repos/asf/commons/proper/math/tags/trunk_tmp_2012-03-01/
{noformat}
--
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] (CHAIN-67) Refactor of explicit Exception throws to a RuntimeException type
[
https://issues.apache.org/jira/browse/CHAIN-67?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Elijah Zupancic updated CHAIN-67:
-
Attachment: chain-67.diff
Patch for adding a new exception type called ChainException.
> Refactor of explicit Exception throws to a RuntimeException type
>
>
> Key: CHAIN-67
> URL: https://issues.apache.org/jira/browse/CHAIN-67
> Project: Commons Chain
> Issue Type: Improvement
>Affects Versions: 2.0
>Reporter: Elijah Zupancic
>Priority: Minor
> Labels: exception-handling
> Fix For: 2.0
>
> Attachments: chain-67.diff
>
> Original Estimate: 2h
> Remaining Estimate: 2h
>
> As I've been working on the examples and the documentation for v2 of
> chain, I've noticed that the API for exception handling of Command and
> Chain is clunky.
> When executing a command like:
> {code:java}
>ProfileContext context = new ProfileContext();
>Command command = new ProfileCheck();
>try {
>command.execute(context);
>}
>catch (Exception e) {
>throw new RuntimeException(e);
>}
> {code}
> The user of chain has to explicitly catch Exception. If the desire was
> to catch the most base error and force the user to deal with it, why
> aren't we using Throwable? Anyways, this design leads to less than
> elegant code and since we will be breaking the API in v2, I would like
> to suggest a different approach.
> I suggest that Command and Chain should throw a custom exception class
> called ChainException that inherits from RuntimeException. And in the
> CommandBase, ChainBase we wrap the catch of Exception in this runtime
> exception. Moreover, we would attach to ChainException some optional
> debug information about the Context invoked when the exception was
> encountered.
--
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] [Created] (CHAIN-67) Refactor of explicit Exception throws to a RuntimeException type
Refactor of explicit Exception throws to a RuntimeException type
Key: CHAIN-67
URL: https://issues.apache.org/jira/browse/CHAIN-67
Project: Commons Chain
Issue Type: Improvement
Affects Versions: 2.0
Reporter: Elijah Zupancic
Priority: Minor
Fix For: 2.0
As I've been working on the examples and the documentation for v2 of
chain, I've noticed that the API for exception handling of Command and
Chain is clunky.
When executing a command like:
{code:java}
ProfileContext context = new ProfileContext();
Command command = new ProfileCheck();
try {
command.execute(context);
}
catch (Exception e) {
throw new RuntimeException(e);
}
{code}
The user of chain has to explicitly catch Exception. If the desire was
to catch the most base error and force the user to deal with it, why
aren't we using Throwable? Anyways, this design leads to less than
elegant code and since we will be breaking the API in v2, I would like
to suggest a different approach.
I suggest that Command and Chain should throw a custom exception class
called ChainException that inherits from RuntimeException. And in the
CommandBase, ChainBase we wrap the catch of Exception in this runtime
exception. Moreover, we would attach to ChainException some optional
debug information about the Context invoked when the exception was
encountered.
--
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-121) QuotedPrintableCodec does not support soft line break per the 'quoted-printable' example on Wikipedia
[ https://issues.apache.org/jira/browse/CODEC-121?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Neidhart updated CODEC-121: -- Attachment: CODEC-121.patch Hi, I worked on this issue and came up with a patch to fully support the quoted-printable spec. There are some simplifications to keep the code still simple and small: * do not split on words like in the wikipedia example, but rather at a fixed position * break at position 73 rather than filling up to pos 76 if possible * treat last two octets separately to simplify the rule that '=' must not be the ultimate or penultimate character > QuotedPrintableCodec does not support soft line break per the > 'quoted-printable' example on Wikipedia > - > > Key: CODEC-121 > URL: https://issues.apache.org/jira/browse/CODEC-121 > Project: Commons Codec > Issue Type: Bug >Affects Versions: 1.5 > Environment: I tested on Windows 7. >Reporter: Java John > Labels: codec, decode, quoted-printable > Fix For: 1.x > > Attachments: CODEC-121.patch > > > Writing a unit test I discovered that the example Wikipedia uses for > quoted-printable data does not decode but instead throws an exception. > Their example is here: http://en.wikipedia.org/wiki/Quoted-printable#Example > test: > String qpdata = "If you believe that truth=3Dbeauty, then surely=20=\r\n" > + > "mathematics is the most beautiful branch of philosophy."; > String expected = "If you believe that truth=beauty, then surely " + > "mathematics is the most beautiful branch of philosophy."; > assertEquals( expected, new QuotedPrintableCodec().decode(qpdata) ); > I suppose I could fix if you like but currently I'm not a registered > developer. -- 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-134) Base32 would decode some invalid Base32 encoded string into arbitrary value
[ https://issues.apache.org/jira/browse/CODEC-134?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13221939#comment-13221939 ] Hanson Char commented on CODEC-134: --- Hi Gary, I think I have a rather nice and elegant patch for this; but if you don't mind waiting, I'd like to get some clearance from my current employer. Thanks. > Base32 would decode some invalid Base32 encoded string into arbitrary value > --- > > Key: CODEC-134 > URL: https://issues.apache.org/jira/browse/CODEC-134 > Project: Commons Codec > Issue Type: Bug >Affects Versions: 1.6 > Environment: All >Reporter: Hanson Char > Labels: security > > Example, there is no byte array value that can be encoded into the string > "C5CYMIHWQUUZMKUGZHGEOSJSQDE4L===", but the existing Base32 implementation > would not reject it but decode it into an arbitrary value which if re-encoded > again using the same implementation would result in the string > "C5CYMIHWQUUZMKUGZHGEOSJSQDE4K===". > Instead of blindly decoding the invalid string, the Base32 codec should > reject it (eg by throwing IlleglArgumentException) to avoid security > exploitation (such as tunneling additional information via seemingly valid > base 32 strings). -- 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-132) BeiderMorseEncoder OOM issues
[ https://issues.apache.org/jira/browse/CODEC-132?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13221933#comment-13221933 ] Thomas Neidhart commented on CODEC-132: --- I digged into this problem, and it is not related to punctuation or other special characters. There are some generic rules defined, that blow up the set of possible phenomes, e.g.: "a" "" "" "(e|o|a)" // hat | call | part Considering you provide random data as input, this single rule will match most likely every single 'a' in the input, and triple the set of phenomes at every occasion. This leads quickly to very large sets and to OOMs of course. I would not consider touching the rules, but instead include a parameter to the PhoneticEngine that defines how many different phonemes I want in the result as a maximum. Limiting the number of new phenomes in PhenomeBuilder.apply to this maximum. For normal text, the number of phenomes is usually small anyway, so a default of 20 sounds reasonable, but should be user-controllable. btw. you could also consider using setting the parameter concat to false, in that case each word is treated separately which should mitigate the problem a bit, as single words are smaller and thus do not suffer so much from the phenome explosion. > BeiderMorseEncoder OOM issues > - > > Key: CODEC-132 > URL: https://issues.apache.org/jira/browse/CODEC-132 > Project: Commons Codec > Issue Type: Bug >Affects Versions: 1.6 >Reporter: Robert Muir > Attachments: CODEC-132_test.patch > > > In Lucene/Solr, we integrated this encoder into the latest release. > Our tests use a variety of random strings, and we have recent jenkins failures > from some input streams (of length <= 10), using huge amounts of memory (e.g. > > 64MB), > resulting in OOM. > I've created a test case (length is 30 here) that will OOM with -Xmx256M. > I haven't dug into this much as to what's causing it, but I suspect there > might be a bug > revolving around certain punctuation characters: we didn't see this happening > until > we beefed up our random string generation to start producing "html-like" > strings. -- 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] [Created] (MATH-762) Duplicate code in "FastMath"
Duplicate code in "FastMath"
Key: MATH-762
URL: https://issues.apache.org/jira/browse/MATH-762
Project: Commons Math
Issue Type: Improvement
Reporter: Gilles
Priority: Minor
Fix For: 3.1
Several methods contain the same loop, marked
{code}
/* Inline the Cody/Waite reduction for performance */
{code}
It should be tested whether this claim is true with modern JIT compilation.
--
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] (SANDBOX-404) Simplify weight model
[
https://issues.apache.org/jira/browse/SANDBOX-404?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13221906#comment-13221906
]
Simone Tripodi commented on SANDBOX-404:
Until there will be _real_ need of adding new Monoid implementations, I would
suggest to postpone the problem and keep *your* version of the patch.
Let's fight with the right weapons when we need, I wouldn't use a katana to
kill a fly (unless I am Bruce Willis and I'm in Pulp Fiction :P)
best and thanks!
-Simo
> Simplify weight model
> -
>
> Key: SANDBOX-404
> URL: https://issues.apache.org/jira/browse/SANDBOX-404
> Project: Commons Sandbox
> Issue Type: Improvement
> Components: Graph
>Reporter: Simone Tripodi
> Attachments: SANDBOX-404.patch,
> SANDBOX-404_gettingRidOfOrderedMonoid.patch
>
>
> As discussed on {{dev@}}, {{Zero}}, {{Semigroup}} and {{Monoid}} can be
> merged directly in one single interface
--
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] (SANDBOX-404) Simplify weight model
[
https://issues.apache.org/jira/browse/SANDBOX-404?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13221901#comment-13221901
]
Claudio Squarcella edited comment on SANDBOX-404 at 3/4/12 2:33 PM:
Hi!
First things first:
My idea is to completely get rid of {{Monoid}}, in favor of a group of
interfaces directly representing operations. In the specific case, {{Addition}}
would immediately "take its place" not semantically but *functionally*, to
cover algorithm needs -- indeed so far we compute "additions" and not generic
"monoid operations", so that would also increase consistency and readability.
It would look more or less like this:
{code}
public interface Addition
{
E sum(E e1, E e2);
E zero();
E negate(E e);
}
{code}
In case later we want to add {{Multiplication}} it will be totally independent,
as explained in my first comment above. Something like:
{code}
public interface Multiplication
{
E multiply(E e1, E e2);
E one(); // or "identity()", we'll see
E reciprocal(E e);
}
{code}
As for the signature change, I did it because I would prefer not to stack
interfaces on top of each other like we did with {{Zero}}, {{Semigroup}},
{{Monoid}} and {{OrderedMonoid}}. As long as we can easily write in the
signatures all the individual properties we need (in the example {{Addition}}
and {{Comparator}}) we can avoid to add interfaces like {{ComparableAddition}},
{{ComparableMultiplication}}, {{ComparableAdditionMultiplication}}... see my
point?
Concluding: I can work on {{Addition}} if, and as soon as, we agree.
Ciao,
Claudio
was (Author: claudio.squarcella):
Hi!
First things first:
My idea is to completely get rid of {{Monoid}}, in favor of a group of
interfaces directly representing operations. In the specific case, {{Addition}}
would immediately "take its place" not semantically but *functionally*, to
cover algorithm needs -- they indeed need to apply "addition" and not a generic
"monoid", so that would also increase consistency. It would look more or less
like this:
{code}
public interface Addition
{
E sum(E e1, E e2);
E zero();
E negate(E e);
}
{code}
In case later we want to add {{Multiplication}} it will be totally independent,
as explained in my first comment above. Something like:
{code}
public interface Multiplication
{
E multiply(E e1, E e2);
E one(); // or "identity()", we'll see
E reciprocal(E e);
}
{code}
As for the signature change, I did it because I would prefer not to stack
interfaces on top of each other like we did with {{Zero}}, {{Semigroup}},
{{Monoid}} and {{OrderedMonoid}}. As long as we can easily write in the
signatures all the individual properties we need (in the example {{Addition}}
and {{Comparator}}) we can avoid to add interfaces like {{ComparableAddition}},
{{ComparableMultiplication}}, {{ComparableAdditionMultiplication}}... see my
point?
Concluding: I can work on {{Addition}} if, and as soon as, we agree.
Ciao,
Claudio
> Simplify weight model
> -
>
> Key: SANDBOX-404
> URL: https://issues.apache.org/jira/browse/SANDBOX-404
> Project: Commons Sandbox
> Issue Type: Improvement
> Components: Graph
>Reporter: Simone Tripodi
> Attachments: SANDBOX-404.patch,
> SANDBOX-404_gettingRidOfOrderedMonoid.patch
>
>
> As discussed on {{dev@}}, {{Zero}}, {{Semigroup}} and {{Monoid}} can be
> merged directly in one single interface
--
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] (SANDBOX-404) Simplify weight model
[
https://issues.apache.org/jira/browse/SANDBOX-404?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13221901#comment-13221901
]
Claudio Squarcella commented on SANDBOX-404:
Hi!
First things first:
My idea is to completely get rid of {{Monoid}}, in favor of a group of
interfaces directly representing operations. In the specific case, {{Addition}}
would immediately "take its place" not semantically but *functionally*, to
cover algorithm needs -- they indeed need to apply "addition" and not a generic
"monoid", so that would also increase consistency. It would look more or less
like this:
{code}
public interface Addition
{
E sum(E e1, E e2);
E zero();
E negate(E e);
}
{code}
In case later we want to add {{Multiplication}} it will be totally independent,
as explained in my first comment above. Something like:
{code}
public interface Multiplication
{
E multiply(E e1, E e2);
E one(); // or "identity()", we'll see
E reciprocal(E e);
}
{code}
As for the signature change, I did it because I would prefer not to stack
interfaces on top of each other like we did with {{Zero}}, {{Semigroup}},
{{Monoid}} and {{OrderedMonoid}}. As long as we can easily write in the
signatures all the individual properties we need (in the example {{Addition}}
and {{Comparator}}) we can avoid to add interfaces like {{ComparableAddition}},
{{ComparableMultiplication}}, {{ComparableAdditionMultiplication}}... see my
point?
Concluding: I can work on {{Addition}} if, and as soon as, we agree.
Ciao,
Claudio
> Simplify weight model
> -
>
> Key: SANDBOX-404
> URL: https://issues.apache.org/jira/browse/SANDBOX-404
> Project: Commons Sandbox
> Issue Type: Improvement
> Components: Graph
>Reporter: Simone Tripodi
> Attachments: SANDBOX-404.patch,
> SANDBOX-404_gettingRidOfOrderedMonoid.patch
>
>
> As discussed on {{dev@}}, {{Zero}}, {{Semigroup}} and {{Monoid}} can be
> merged directly in one single interface
--
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] (LANG-777) jar contains velocity template of release notes
[ https://issues.apache.org/jira/browse/LANG-777?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13221899#comment-13221899 ] Thomas Neidhart commented on LANG-777: -- The parent pom version 23 defines as default location for the release-notes template: src/changes/release-notes.vm src/changes/changes.xml So the templates can not slip into the resulting jar. CM3 for example already follows this scheme. > jar contains velocity template of release notes > --- > > Key: LANG-777 > URL: https://issues.apache.org/jira/browse/LANG-777 > Project: Commons Lang > Issue Type: Bug > Components: General >Affects Versions: 3.1 >Reporter: Joerg Schaible >Priority: Trivial > Labels: build > > The released Java archive of 3.1 contains the velocity template > "release-notes.vm" (claiming to be for 3.0.1 anyway) in the Java package > "templates". -- 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-134) Base32 would decode some invalid Base32 encoded string into arbitrary value
[ https://issues.apache.org/jira/browse/CODEC-134?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13221889#comment-13221889 ] Gary D. Gregory commented on CODEC-134: --- Note that we might elect to file this in the garbage-in-garbage-out category. > Base32 would decode some invalid Base32 encoded string into arbitrary value > --- > > Key: CODEC-134 > URL: https://issues.apache.org/jira/browse/CODEC-134 > Project: Commons Codec > Issue Type: Bug >Affects Versions: 1.6 > Environment: All >Reporter: Hanson Char > Labels: security > > Example, there is no byte array value that can be encoded into the string > "C5CYMIHWQUUZMKUGZHGEOSJSQDE4L===", but the existing Base32 implementation > would not reject it but decode it into an arbitrary value which if re-encoded > again using the same implementation would result in the string > "C5CYMIHWQUUZMKUGZHGEOSJSQDE4K===". > Instead of blindly decoding the invalid string, the Base32 codec should > reject it (eg by throwing IlleglArgumentException) to avoid security > exploitation (such as tunneling additional information via seemingly valid > base 32 strings). -- 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-134) Base32 would decode some invalid Base32 encoded string into arbitrary value
[ https://issues.apache.org/jira/browse/CODEC-134?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13221888#comment-13221888 ] Gary D. Gregory commented on CODEC-134: --- Can you please provide a patch? > Base32 would decode some invalid Base32 encoded string into arbitrary value > --- > > Key: CODEC-134 > URL: https://issues.apache.org/jira/browse/CODEC-134 > Project: Commons Codec > Issue Type: Bug >Affects Versions: 1.6 > Environment: All >Reporter: Hanson Char > Labels: security > > Example, there is no byte array value that can be encoded into the string > "C5CYMIHWQUUZMKUGZHGEOSJSQDE4L===", but the existing Base32 implementation > would not reject it but decode it into an arbitrary value which if re-encoded > again using the same implementation would result in the string > "C5CYMIHWQUUZMKUGZHGEOSJSQDE4K===". > Instead of blindly decoding the invalid string, the Base32 codec should > reject it (eg by throwing IlleglArgumentException) to avoid security > exploitation (such as tunneling additional information via seemingly valid > base 32 strings). -- 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] (LANG-790) Null safe Navigation in ObjectUtils
[ https://issues.apache.org/jira/browse/LANG-790?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13221887#comment-13221887 ] Gary D. Gregory commented on LANG-790: -- This feels out of scope. Why not use JXPath? > Null safe Navigation in ObjectUtils > --- > > Key: LANG-790 > URL: https://issues.apache.org/jira/browse/LANG-790 > Project: Commons Lang > Issue Type: New Feature >Reporter: Gokul Nanthakumar C > > Adding a method for null safe navigation of objects will be very helpful. for > example a method like > ObjectUtils.getValue(Object obj, String "path", String defaultValue); > ex :ObjectUtils.getValue(myObject, "x.y.z", "default"); > it will navigate in the myObject like myObject.getX().getY().getZ(), if any > thing in the path is null (x,y or z), it will return the default value. > It will be really useful, it is like null safe navigation in groovy. -- 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] (SANDBOX-404) Simplify weight model
[
https://issues.apache.org/jira/browse/SANDBOX-404?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13221877#comment-13221877
]
Simone Tripodi commented on SANDBOX-404:
hola,
having a look at the patch I am not really happy on how signatures heavily
changed, once dropped the {{OrderedMonoid}}, but I can safety live with it.
The rename instead doesn't convince me at all: {{Monoid}} perfectly reflects
the monoid definition - it is an interface indeed - {{Addition}} is one monoid
*instance*. What is we have to add more Monoid operations? Do you intend to
create new monoid for each operation?
> Simplify weight model
> -
>
> Key: SANDBOX-404
> URL: https://issues.apache.org/jira/browse/SANDBOX-404
> Project: Commons Sandbox
> Issue Type: Improvement
> Components: Graph
>Reporter: Simone Tripodi
> Attachments: SANDBOX-404.patch,
> SANDBOX-404_gettingRidOfOrderedMonoid.patch
>
>
> As discussed on {{dev@}}, {{Zero}}, {{Semigroup}} and {{Monoid}} can be
> merged directly in one single interface
--
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] (SANDBOX-404) Simplify weight model
[
https://issues.apache.org/jira/browse/SANDBOX-404?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13221749#comment-13221749
]
Claudio Squarcella edited comment on SANDBOX-404 at 3/4/12 10:18 AM:
-
Hi Simone,
I am attaching a patch that begins with yours and goes one step further,
getting rid of {{OrderedMonoid}} basically everywhere (although I did not
delete {{OrderedMonoid}} itself for now) and replacing it with {{Monoid &
Comparator}}. That has two reasons:
* separating main operations/properties, so that every algorithm specifies what
is needed in terms of a set of interfaces;
* leading the way to the next refactoring step where {{Monoid}} is converted
into {{Addition}}, in order to better represent what it actually does.
So one step is missing, i.e. renaming {{Monoid}} to {{Addition}} (and
{{Monoid#append}} to {{Addition#sum}}, etc) -- but first I want to get some
feedback on this one.
Ciao
Claudio
was (Author: claudio.squarcella):
Hi Simone,
I am attaching a patch that begins with yours and goes one step further,
getting rid of {{OrderedMonoid}} basically everywhere and replacing it with
{{Monoid & Comparator}}. That has two reasons:
* separating main operations/properties, so that every algorithm specifies what
is needed in terms of a set of interfaces;
* leading the way to the next refactoring step where {{Monoid}} is converted
into {{Addition}}, in order to better represent what it actually does.
So one step is missing, i.e. renaming {{Monoid}} into {{Addition}} (and
{{Monoid#append}} into {{Addition#sum}}, etc) -- but I first wanted to get some
feedback on this one.
Ciao
Claudio
> Simplify weight model
> -
>
> Key: SANDBOX-404
> URL: https://issues.apache.org/jira/browse/SANDBOX-404
> Project: Commons Sandbox
> Issue Type: Improvement
> Components: Graph
>Reporter: Simone Tripodi
> Attachments: SANDBOX-404.patch,
> SANDBOX-404_gettingRidOfOrderedMonoid.patch
>
>
> As discussed on {{dev@}}, {{Zero}}, {{Semigroup}} and {{Monoid}} can be
> merged directly in one single interface
--
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
