[
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
