You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@cassandra.apache.org by "David Allsopp (JIRA)" <ji...@apache.org> on 2011/07/03 20:06:21 UTC
[jira] [Created] (CASSANDRA-2851) hex-to-bytes conversion accepts
invalid inputs silently
hex-to-bytes conversion accepts invalid inputs silently
-------------------------------------------------------
Key: CASSANDRA-2851
URL: https://issues.apache.org/jira/browse/CASSANDRA-2851
Project: Cassandra
Issue Type: Bug
Components: Core
Affects Versions: 0.8.1, 0.7.6
Reporter: David Allsopp
Priority: Minor
Fix For: 0.8.2
FBUtilities.hexToBytes() has a minor bug - it copes with single-character inputs by prepending "0", which is OK - but it does this for any input with an odd number of characters, which is probably incorrect.
{noformat}
if (str.length() % 2 == 1)
str = "0" + str;
{noformat}
Given 'fff' as an input, can we really assume that this should be '0fff'? Isn't this just an error?
Add the following to FBUtilitiesTest to demonstrate:
{noformat}
String[] badvalues = new String[]{"", "000", "fff"};
for (int i = 0; i < badvalues.length; i++)
try
{
FBUtilities.hexToBytes(badvalues[i]);
fail("Invalid hex value accepted"+badvalues[i]);
} catch (Exception e){}
{noformat}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2851) hex-to-bytes conversion accepts
invalid inputs silently
Posted by "David Allsopp (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-2851?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13103513#comment-13103513 ]
David Allsopp commented on CASSANDRA-2851:
------------------------------------------
Sounds good to me - I agree the underlying conversion should be strict to
avoid inadvertent misuse and hidden bugs in future - with a more lenient
wrapper for specific cases and backward compatibility.
> hex-to-bytes conversion accepts invalid inputs silently
> -------------------------------------------------------
>
> Key: CASSANDRA-2851
> URL: https://issues.apache.org/jira/browse/CASSANDRA-2851
> Project: Cassandra
> Issue Type: Bug
> Components: Core
> Affects Versions: 0.7.6, 0.8.1
> Reporter: David Allsopp
> Priority: Minor
> Fix For: 1.1
>
> Attachments: cassandra-2851.diff
>
>
> FBUtilities.hexToBytes() has a minor bug - it copes with single-character inputs by prepending "0", which is OK - but it does this for any input with an odd number of characters, which is probably incorrect.
> {noformat}
> if (str.length() % 2 == 1)
> str = "0" + str;
> {noformat}
> Given 'fff' as an input, can we really assume that this should be '0fff'? Isn't this just an error?
> Add the following to FBUtilitiesTest to demonstrate:
> {noformat}
> String[] badvalues = new String[]{"000", "fff"};
>
> for (int i = 0; i < badvalues.length; i++)
> try
> {
> FBUtilities.hexToBytes(badvalues[i]);
> fail("Invalid hex value accepted"+badvalues[i]);
> } catch (Exception e){}
> {noformat}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2851) hex-to-bytes conversion accepts
invalid inputs silently
Posted by "Sylvain Lebresne (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-2851?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13059362#comment-13059362 ]
Sylvain Lebresne commented on CASSANDRA-2851:
---------------------------------------------
Why would it be ok for single-character inputs and not other odd-sized inputs ? An odd-sized input doesn't (ever) correspond to a valid byte array, so I'd say either we always silently add a 0 to "make it fit" or we never do it. I do actually am in favor of throwing an exception rather then coping with it silently since it's more likely to indicate a user error than to be helpful (but maybe that addition of a '0' in front was there for a reason?).
I'll note that even though I can't imagine why people would generate odd-sized hex input, since it is allowed so far, there is a chance someone out there does it, and it would be a "regression" for that guy. So maybe we should target 1.0 for the sake of making minor upgrade as smooth for everybody as can be.
On the patch side, we must make sure every consumer of hexToBytes() handles the new exception (or make it a NumberFormatException but I don't think this is a good idea). For instance, at least BytesType.fromString() should catch the IllegalArgumentException and rethrow a MarshalException, otherwise CQL will crap his pants on odd-sized inputs.
> hex-to-bytes conversion accepts invalid inputs silently
> -------------------------------------------------------
>
> Key: CASSANDRA-2851
> URL: https://issues.apache.org/jira/browse/CASSANDRA-2851
> Project: Cassandra
> Issue Type: Bug
> Components: Core
> Affects Versions: 0.7.6, 0.8.1
> Reporter: David Allsopp
> Priority: Minor
> Fix For: 0.8.2
>
> Attachments: cassandra-2851.diff
>
>
> FBUtilities.hexToBytes() has a minor bug - it copes with single-character inputs by prepending "0", which is OK - but it does this for any input with an odd number of characters, which is probably incorrect.
> {noformat}
> if (str.length() % 2 == 1)
> str = "0" + str;
> {noformat}
> Given 'fff' as an input, can we really assume that this should be '0fff'? Isn't this just an error?
> Add the following to FBUtilitiesTest to demonstrate:
> {noformat}
> String[] badvalues = new String[]{"000", "fff"};
>
> for (int i = 0; i < badvalues.length; i++)
> try
> {
> FBUtilities.hexToBytes(badvalues[i]);
> fail("Invalid hex value accepted"+badvalues[i]);
> } catch (Exception e){}
> {noformat}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-2851) hex-to-bytes conversion accepts
invalid inputs silently
Posted by "David Allsopp (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-2851?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
David Allsopp updated CASSANDRA-2851:
-------------------------------------
Attachment: cassandra-2851.diff
If there's agreement that odd-sized inputs should throw an exception, the attached patch does this and updates the unit test.
> hex-to-bytes conversion accepts invalid inputs silently
> -------------------------------------------------------
>
> Key: CASSANDRA-2851
> URL: https://issues.apache.org/jira/browse/CASSANDRA-2851
> Project: Cassandra
> Issue Type: Bug
> Components: Core
> Affects Versions: 0.7.6, 0.8.1
> Reporter: David Allsopp
> Priority: Minor
> Fix For: 0.8.2
>
> Attachments: cassandra-2851.diff
>
>
> FBUtilities.hexToBytes() has a minor bug - it copes with single-character inputs by prepending "0", which is OK - but it does this for any input with an odd number of characters, which is probably incorrect.
> {noformat}
> if (str.length() % 2 == 1)
> str = "0" + str;
> {noformat}
> Given 'fff' as an input, can we really assume that this should be '0fff'? Isn't this just an error?
> Add the following to FBUtilitiesTest to demonstrate:
> {noformat}
> String[] badvalues = new String[]{"000", "fff"};
>
> for (int i = 0; i < badvalues.length; i++)
> try
> {
> FBUtilities.hexToBytes(badvalues[i]);
> fail("Invalid hex value accepted"+badvalues[i]);
> } catch (Exception e){}
> {noformat}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-2851) hex-to-bytes conversion accepts
invalid inputs silently
Posted by "Sylvain Lebresne (Updated) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-2851?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Sylvain Lebresne updated CASSANDRA-2851:
----------------------------------------
Attachment: 2851.patch
Attaching patch that implements the idea above, i.e. hexToBytes throw an exception on odd number of input characters, but silently adds a '0' in front when parsing a token for an ordered partitioner.
This does mean BytesType will throw a MarshalException when given a string of odd length. I think it is a good thing, it was a but that we were potentially silently adding some zeroes to column names or values given by the user. However, this does kind of break some form of backward compatibility so I suppose we should either push it for 1.1.0 or report to 1.2. I personally would be good for 1.1.0 (I consider the current behavior a bug) but I won't argue if someone prefers 1.2.
> hex-to-bytes conversion accepts invalid inputs silently
> -------------------------------------------------------
>
> Key: CASSANDRA-2851
> URL: https://issues.apache.org/jira/browse/CASSANDRA-2851
> Project: Cassandra
> Issue Type: Bug
> Components: Core
> Affects Versions: 0.7.6, 0.8.1
> Reporter: David Allsopp
> Priority: Minor
> Fix For: 1.1.1
>
> Attachments: 2851.patch, cassandra-2851.diff
>
>
> FBUtilities.hexToBytes() has a minor bug - it copes with single-character inputs by prepending "0", which is OK - but it does this for any input with an odd number of characters, which is probably incorrect.
> {noformat}
> if (str.length() % 2 == 1)
> str = "0" + str;
> {noformat}
> Given 'fff' as an input, can we really assume that this should be '0fff'? Isn't this just an error?
> Add the following to FBUtilitiesTest to demonstrate:
> {noformat}
> String[] badvalues = new String[]{"000", "fff"};
>
> for (int i = 0; i < badvalues.length; i++)
> try
> {
> FBUtilities.hexToBytes(badvalues[i]);
> fail("Invalid hex value accepted"+badvalues[i]);
> } catch (Exception e){}
> {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] [Commented] (CASSANDRA-2851) hex-to-bytes conversion accepts
invalid inputs silently
Posted by "Jonathan Ellis (Commented) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-2851?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13205455#comment-13205455 ]
Jonathan Ellis commented on CASSANDRA-2851:
-------------------------------------------
+1 for 1.1.0 from me
> hex-to-bytes conversion accepts invalid inputs silently
> -------------------------------------------------------
>
> Key: CASSANDRA-2851
> URL: https://issues.apache.org/jira/browse/CASSANDRA-2851
> Project: Cassandra
> Issue Type: Bug
> Components: Core
> Affects Versions: 0.7.6, 0.8.1
> Reporter: David Allsopp
> Priority: Minor
> Fix For: 1.1.1
>
> Attachments: 2851.patch, cassandra-2851.diff
>
>
> FBUtilities.hexToBytes() has a minor bug - it copes with single-character inputs by prepending "0", which is OK - but it does this for any input with an odd number of characters, which is probably incorrect.
> {noformat}
> if (str.length() % 2 == 1)
> str = "0" + str;
> {noformat}
> Given 'fff' as an input, can we really assume that this should be '0fff'? Isn't this just an error?
> Add the following to FBUtilitiesTest to demonstrate:
> {noformat}
> String[] badvalues = new String[]{"000", "fff"};
>
> for (int i = 0; i < badvalues.length; i++)
> try
> {
> FBUtilities.hexToBytes(badvalues[i]);
> fail("Invalid hex value accepted"+badvalues[i]);
> } catch (Exception e){}
> {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] [Commented] (CASSANDRA-2851) hex-to-bytes conversion accepts
invalid inputs silently
Posted by "Jonathan Ellis (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-2851?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13059413#comment-13059413 ]
Jonathan Ellis commented on CASSANDRA-2851:
-------------------------------------------
bq. maybe that addition of a '0' in front was there for a reason
I think it's there b/c of Integer.toHexString: "This value is converted to a string of ASCII digits in hexadecimal (base 16) with no extra leading 0s."
Our bytesToHex does pad... but only for single-digit results. So if we fix hexToBytes we'll introduce an incompatibility. (Granted, a minor one.)
> hex-to-bytes conversion accepts invalid inputs silently
> -------------------------------------------------------
>
> Key: CASSANDRA-2851
> URL: https://issues.apache.org/jira/browse/CASSANDRA-2851
> Project: Cassandra
> Issue Type: Bug
> Components: Core
> Affects Versions: 0.7.6, 0.8.1
> Reporter: David Allsopp
> Priority: Minor
> Fix For: 0.8.2
>
> Attachments: cassandra-2851.diff
>
>
> FBUtilities.hexToBytes() has a minor bug - it copes with single-character inputs by prepending "0", which is OK - but it does this for any input with an odd number of characters, which is probably incorrect.
> {noformat}
> if (str.length() % 2 == 1)
> str = "0" + str;
> {noformat}
> Given 'fff' as an input, can we really assume that this should be '0fff'? Isn't this just an error?
> Add the following to FBUtilitiesTest to demonstrate:
> {noformat}
> String[] badvalues = new String[]{"000", "fff"};
>
> for (int i = 0; i < badvalues.length; i++)
> try
> {
> FBUtilities.hexToBytes(badvalues[i]);
> fail("Invalid hex value accepted"+badvalues[i]);
> } catch (Exception e){}
> {noformat}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2851) hex-to-bytes conversion accepts
invalid inputs silently
Posted by "Sylvain Lebresne (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-2851?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13059484#comment-13059484 ]
Sylvain Lebresne commented on CASSANDRA-2851:
---------------------------------------------
bq. Our bytesToHex does pad... but only for single-digit results. So if we fix hexToBytes we'll introduce an incompatibility. (Granted, a minor one.)
I don't understand. There is no such thing as padding when you convert a byte array to hex (Integer.toHexString does return only the right number of hexadecimal digits because it has no reason to do otherwise, but it's an implementation detail of bytesToHex). A byte is always 8 bit, never 4, and the output of bytesToHex will *always* have a even number of characters (as it should). Our hexToBytes just happen to semi-randomly add 0 in front to transform a buggy input with an odd number of character to a even one, in the off chance that a client used the (stupid) "optimization" of removing at most 1 leading 0 to win some space or something. In my opinion, it would be better to simply refuse odd sized input because this is more likely a truncated input (and people using stupid clients should fix them, though I'm ok with saying that we'll force them to fix it only on a major upgrade).
> hex-to-bytes conversion accepts invalid inputs silently
> -------------------------------------------------------
>
> Key: CASSANDRA-2851
> URL: https://issues.apache.org/jira/browse/CASSANDRA-2851
> Project: Cassandra
> Issue Type: Bug
> Components: Core
> Affects Versions: 0.7.6, 0.8.1
> Reporter: David Allsopp
> Priority: Minor
> Fix For: 0.8.2
>
> Attachments: cassandra-2851.diff
>
>
> FBUtilities.hexToBytes() has a minor bug - it copes with single-character inputs by prepending "0", which is OK - but it does this for any input with an odd number of characters, which is probably incorrect.
> {noformat}
> if (str.length() % 2 == 1)
> str = "0" + str;
> {noformat}
> Given 'fff' as an input, can we really assume that this should be '0fff'? Isn't this just an error?
> Add the following to FBUtilitiesTest to demonstrate:
> {noformat}
> String[] badvalues = new String[]{"000", "fff"};
>
> for (int i = 0; i < badvalues.length; i++)
> try
> {
> FBUtilities.hexToBytes(badvalues[i]);
> fail("Invalid hex value accepted"+badvalues[i]);
> } catch (Exception e){}
> {noformat}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2851) hex-to-bytes conversion accepts
invalid inputs silently
Posted by "Jonathan Ellis (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-2851?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13059500#comment-13059500 ]
Jonathan Ellis commented on CASSANDRA-2851:
-------------------------------------------
You're right, I was misreading how we were using Integer.toHexString.
> hex-to-bytes conversion accepts invalid inputs silently
> -------------------------------------------------------
>
> Key: CASSANDRA-2851
> URL: https://issues.apache.org/jira/browse/CASSANDRA-2851
> Project: Cassandra
> Issue Type: Bug
> Components: Core
> Affects Versions: 0.7.6, 0.8.1
> Reporter: David Allsopp
> Priority: Minor
> Fix For: 0.8.2
>
> Attachments: cassandra-2851.diff
>
>
> FBUtilities.hexToBytes() has a minor bug - it copes with single-character inputs by prepending "0", which is OK - but it does this for any input with an odd number of characters, which is probably incorrect.
> {noformat}
> if (str.length() % 2 == 1)
> str = "0" + str;
> {noformat}
> Given 'fff' as an input, can we really assume that this should be '0fff'? Isn't this just an error?
> Add the following to FBUtilitiesTest to demonstrate:
> {noformat}
> String[] badvalues = new String[]{"000", "fff"};
>
> for (int i = 0; i < badvalues.length; i++)
> try
> {
> FBUtilities.hexToBytes(badvalues[i]);
> fail("Invalid hex value accepted"+badvalues[i]);
> } catch (Exception e){}
> {noformat}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2851) hex-to-bytes conversion accepts
invalid inputs silently
Posted by "David Allsopp (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-2851?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13059246#comment-13059246 ]
David Allsopp commented on CASSANDRA-2851:
------------------------------------------
In addition to the invalid values, should probably also add a check in FBUtilitiesTest.testHexToBytesStringConversion() that "" is converted to byte[0], and that a null input is handled appropriately.
> hex-to-bytes conversion accepts invalid inputs silently
> -------------------------------------------------------
>
> Key: CASSANDRA-2851
> URL: https://issues.apache.org/jira/browse/CASSANDRA-2851
> Project: Cassandra
> Issue Type: Bug
> Components: Core
> Affects Versions: 0.7.6, 0.8.1
> Reporter: David Allsopp
> Priority: Minor
> Fix For: 0.8.2
>
>
> FBUtilities.hexToBytes() has a minor bug - it copes with single-character inputs by prepending "0", which is OK - but it does this for any input with an odd number of characters, which is probably incorrect.
> {noformat}
> if (str.length() % 2 == 1)
> str = "0" + str;
> {noformat}
> Given 'fff' as an input, can we really assume that this should be '0fff'? Isn't this just an error?
> Add the following to FBUtilitiesTest to demonstrate:
> {noformat}
> String[] badvalues = new String[]{"", "000", "fff"};
>
> for (int i = 0; i < badvalues.length; i++)
> try
> {
> FBUtilities.hexToBytes(badvalues[i]);
> fail("Invalid hex value accepted"+badvalues[i]);
> } catch (Exception e){}
> {noformat}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-2851) hex-to-bytes conversion accepts
invalid inputs silently
Posted by "David Allsopp (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-2851?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
David Allsopp updated CASSANDRA-2851:
-------------------------------------
Description:
FBUtilities.hexToBytes() has a minor bug - it copes with single-character inputs by prepending "0", which is OK - but it does this for any input with an odd number of characters, which is probably incorrect.
{noformat}
if (str.length() % 2 == 1)
str = "0" + str;
{noformat}
Given 'fff' as an input, can we really assume that this should be '0fff'? Isn't this just an error?
Add the following to FBUtilitiesTest to demonstrate:
{noformat}
String[] badvalues = new String[]{"000", "fff"};
for (int i = 0; i < badvalues.length; i++)
try
{
FBUtilities.hexToBytes(badvalues[i]);
fail("Invalid hex value accepted"+badvalues[i]);
} catch (Exception e){}
{noformat}
was:
FBUtilities.hexToBytes() has a minor bug - it copes with single-character inputs by prepending "0", which is OK - but it does this for any input with an odd number of characters, which is probably incorrect.
{noformat}
if (str.length() % 2 == 1)
str = "0" + str;
{noformat}
Given 'fff' as an input, can we really assume that this should be '0fff'? Isn't this just an error?
Add the following to FBUtilitiesTest to demonstrate:
{noformat}
String[] badvalues = new String[]{"", "000", "fff"};
for (int i = 0; i < badvalues.length; i++)
try
{
FBUtilities.hexToBytes(badvalues[i]);
fail("Invalid hex value accepted"+badvalues[i]);
} catch (Exception e){}
{noformat}
> hex-to-bytes conversion accepts invalid inputs silently
> -------------------------------------------------------
>
> Key: CASSANDRA-2851
> URL: https://issues.apache.org/jira/browse/CASSANDRA-2851
> Project: Cassandra
> Issue Type: Bug
> Components: Core
> Affects Versions: 0.7.6, 0.8.1
> Reporter: David Allsopp
> Priority: Minor
> Fix For: 0.8.2
>
>
> FBUtilities.hexToBytes() has a minor bug - it copes with single-character inputs by prepending "0", which is OK - but it does this for any input with an odd number of characters, which is probably incorrect.
> {noformat}
> if (str.length() % 2 == 1)
> str = "0" + str;
> {noformat}
> Given 'fff' as an input, can we really assume that this should be '0fff'? Isn't this just an error?
> Add the following to FBUtilitiesTest to demonstrate:
> {noformat}
> String[] badvalues = new String[]{"000", "fff"};
>
> for (int i = 0; i < badvalues.length; i++)
> try
> {
> FBUtilities.hexToBytes(badvalues[i]);
> fail("Invalid hex value accepted"+badvalues[i]);
> } catch (Exception e){}
> {noformat}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2851) hex-to-bytes conversion accepts
invalid inputs silently
Posted by "Sylvain Lebresne (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-2851?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13100184#comment-13100184 ]
Sylvain Lebresne commented on CASSANDRA-2851:
---------------------------------------------
bq. Sounds like the problem is thinking of this as a generic hex conversion function, rather than as "hex that specifically represents bytes."
Well, in a way those methods never pretended being generic hex to *bits* conversion functions since they are called hex2bytes and bytes2hex. I still think that the correct behavior for hex2bytes is to throw an exception on odd sized input. And that CASSANDRA-1411 was a mistake: yes I understand that it's annoying the first time you use '0' as token to get an exception and to have to write '00', but if you had written '0', there is a good chance you had missed the meaning of the input, i.e that it is an hex string representing a byte array.
Now changing that behavior would not be backward compatible, so I wonder if we really should do anything here. I would be in favor however to refactor the code slightly so that hex2bytes do throw an exception on odd sized input (it would be fine if the method was named hex2bits, but it's fishy with hex2bytes) and to move the code that pads the input into ByteOrderedPartitioner, since that is what it was meant to: simplify the input of tokens.
> hex-to-bytes conversion accepts invalid inputs silently
> -------------------------------------------------------
>
> Key: CASSANDRA-2851
> URL: https://issues.apache.org/jira/browse/CASSANDRA-2851
> Project: Cassandra
> Issue Type: Bug
> Components: Core
> Affects Versions: 0.7.6, 0.8.1
> Reporter: David Allsopp
> Priority: Minor
> Fix For: 1.0
>
> Attachments: cassandra-2851.diff
>
>
> FBUtilities.hexToBytes() has a minor bug - it copes with single-character inputs by prepending "0", which is OK - but it does this for any input with an odd number of characters, which is probably incorrect.
> {noformat}
> if (str.length() % 2 == 1)
> str = "0" + str;
> {noformat}
> Given 'fff' as an input, can we really assume that this should be '0fff'? Isn't this just an error?
> Add the following to FBUtilitiesTest to demonstrate:
> {noformat}
> String[] badvalues = new String[]{"000", "fff"};
>
> for (int i = 0; i < badvalues.length; i++)
> try
> {
> FBUtilities.hexToBytes(badvalues[i]);
> fail("Invalid hex value accepted"+badvalues[i]);
> } catch (Exception e){}
> {noformat}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2851) hex-to-bytes conversion accepts
invalid inputs silently
Posted by "Jonathan Ellis (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-2851?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13100287#comment-13100287 ]
Jonathan Ellis commented on CASSANDRA-2851:
-------------------------------------------
That sounds reasonable.
> hex-to-bytes conversion accepts invalid inputs silently
> -------------------------------------------------------
>
> Key: CASSANDRA-2851
> URL: https://issues.apache.org/jira/browse/CASSANDRA-2851
> Project: Cassandra
> Issue Type: Bug
> Components: Core
> Affects Versions: 0.7.6, 0.8.1
> Reporter: David Allsopp
> Priority: Minor
> Fix For: 1.1
>
> Attachments: cassandra-2851.diff
>
>
> FBUtilities.hexToBytes() has a minor bug - it copes with single-character inputs by prepending "0", which is OK - but it does this for any input with an odd number of characters, which is probably incorrect.
> {noformat}
> if (str.length() % 2 == 1)
> str = "0" + str;
> {noformat}
> Given 'fff' as an input, can we really assume that this should be '0fff'? Isn't this just an error?
> Add the following to FBUtilitiesTest to demonstrate:
> {noformat}
> String[] badvalues = new String[]{"000", "fff"};
>
> for (int i = 0; i < badvalues.length; i++)
> try
> {
> FBUtilities.hexToBytes(badvalues[i]);
> fail("Invalid hex value accepted"+badvalues[i]);
> } catch (Exception e){}
> {noformat}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2851) hex-to-bytes conversion accepts
invalid inputs silently
Posted by "Jonathan Ellis (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-2851?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13059582#comment-13059582 ]
Jonathan Ellis commented on CASSANDRA-2851:
-------------------------------------------
Good point, David.
Sounds like the problem is thinking of this as a generic hex conversion function, rather than as "hex that specifically represents bytes."
> hex-to-bytes conversion accepts invalid inputs silently
> -------------------------------------------------------
>
> Key: CASSANDRA-2851
> URL: https://issues.apache.org/jira/browse/CASSANDRA-2851
> Project: Cassandra
> Issue Type: Bug
> Components: Core
> Affects Versions: 0.7.6, 0.8.1
> Reporter: David Allsopp
> Priority: Minor
> Fix For: 0.8.2
>
> Attachments: cassandra-2851.diff
>
>
> FBUtilities.hexToBytes() has a minor bug - it copes with single-character inputs by prepending "0", which is OK - but it does this for any input with an odd number of characters, which is probably incorrect.
> {noformat}
> if (str.length() % 2 == 1)
> str = "0" + str;
> {noformat}
> Given 'fff' as an input, can we really assume that this should be '0fff'? Isn't this just an error?
> Add the following to FBUtilitiesTest to demonstrate:
> {noformat}
> String[] badvalues = new String[]{"000", "fff"};
>
> for (int i = 0; i < badvalues.length; i++)
> try
> {
> FBUtilities.hexToBytes(badvalues[i]);
> fail("Invalid hex value accepted"+badvalues[i]);
> } catch (Exception e){}
> {noformat}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2851) hex-to-bytes conversion accepts
invalid inputs silently
Posted by "David Allsopp (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-2851?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13059526#comment-13059526 ]
David Allsopp commented on CASSANDRA-2851:
------------------------------------------
The origin of the current behaviour is CASSANDRA-1411 https://issues.apache.org/jira/browse/CASSANDRA-1411 if that helps...
> hex-to-bytes conversion accepts invalid inputs silently
> -------------------------------------------------------
>
> Key: CASSANDRA-2851
> URL: https://issues.apache.org/jira/browse/CASSANDRA-2851
> Project: Cassandra
> Issue Type: Bug
> Components: Core
> Affects Versions: 0.7.6, 0.8.1
> Reporter: David Allsopp
> Priority: Minor
> Fix For: 0.8.2
>
> Attachments: cassandra-2851.diff
>
>
> FBUtilities.hexToBytes() has a minor bug - it copes with single-character inputs by prepending "0", which is OK - but it does this for any input with an odd number of characters, which is probably incorrect.
> {noformat}
> if (str.length() % 2 == 1)
> str = "0" + str;
> {noformat}
> Given 'fff' as an input, can we really assume that this should be '0fff'? Isn't this just an error?
> Add the following to FBUtilitiesTest to demonstrate:
> {noformat}
> String[] badvalues = new String[]{"000", "fff"};
>
> for (int i = 0; i < badvalues.length; i++)
> try
> {
> FBUtilities.hexToBytes(badvalues[i]);
> fail("Invalid hex value accepted"+badvalues[i]);
> } catch (Exception e){}
> {noformat}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira