BIND 10 #1638: NSEC3PARAM rdata should have more tests

[BIND 10 Development]

#1638: NSEC3PARAM rdata should have more tests
-------------------------------------+-------------------------------------
                   Reporter:         |                 Owner:  jinmei
  jinmei                             |                Status:  reviewing
                       Type:         |             Milestone:
  defect                             |  Sprint-20120221
                   Priority:  major  |            Resolution:
                  Component:         |             Sensitive:  0
  libdns++                           |           Sub-Project:  DNS
                   Keywords:         |  Estimated Difficulty:  6
            Defect Severity:  N/A    |           Total Hours:  0
Feature Depending on Ticket:         |
        Add Hours to Ticket:  0      |
                  Internal?:  0      |
-------------------------------------+-------------------------------------

Comment (by jinmei):

 Replying to [comment:7 jelte]:

 Thanks for the prompt review.

 > Looks good, two minor comments;
 >
 > nsec3param_common.cc:
 >
 > If i read parseNSEC3ParamText() correctly, and salt is too long, it is
 still put into the passed vector. Perhaps not much of a problem (since
 this is in essence a private function and we control the vector), but
 technically not exception-safe. Perhaps do the length check on salthex
 instead of the result vector (whitespace is not allowed anyway)? (or,
 alternatively, mention this explicitely in the doxygen)

 Hmm, good point.  In terms of exception safety the original code was
 actually "safe", in that it didn't cause any resource leak on
 exception (it still didn't provide the strong guarantee, but that is
 not specific to this error case), but being proactive would be
 generally good.  I checked the BIND 9 implementation and found it
 checked too long salt before decoding it, too.  So I changed it.

 BTW: in NSEC3 we check too long hash after decoding.  BIND 9 also does
 that check after decoding.  That's probably because it's not so
 obvious to calculate the possible maximum base32 size (space isn't
 allowed for hash either so in theory it shouldn't be so different -
 but the result would be less readable compared to the case of HEX).

 > nsec3_50.cc:
 >
 > trivial inline comment suggestion: change 'It must not be a padded
 base32hex string.' to 'It must be an unpadded base32hex string" (current
 text might be interpreted as 'must not be base32')

 Okay, changed.

 Giving the ticket back to you just in case.

-- 
Ticket URL: <http://bind10.isc.org/ticket/1638#comment:8>
BIND 10 Development <http://bind10.isc.org>
BIND 10 Development