sahvx655-wq opened a new pull request, #434:
URL: https://github.com/apache/commons-validator/pull/434
convertToISBN13 says in its Javadoc that it returns null when the ISBN-10 is
not valid, but tracing the method shows it only rejects a null argument and a
length other than ten, then builds the ISBN-13 from the first nine characters
and appends a freshly calculated EAN-13 check digit. The ISBN-10 check digit
itself is never verified, so a well-formed ten-digit code with the wrong check
digit slips straight through: convertToISBN13("1234567890") returns
"9781234567897", and isValidISBN13 then reports that manufactured code as
valid. The root cause is a missing validity check, not the length guard, which
already behaves as documented.
The sibling ISSNValidator.convertToEAN13 handles this correctly by calling
validate() first and returning null on failure, so I mirrored that here: after
the length check convertToISBN13 now returns null when isbn10Validator.isValid
rejects the input. The guard belongs in the converter because the public method
owns the null-for-invalid contract, and the internal validate() path is
unchanged since it only ever passes codes it has already validated. Left as is,
the method quietly turns an invalid ISBN-10 into a plausible ISBN-13, which is
exactly the sort of bad data a validator is meant to stop.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
