BIND 10 #2124: RFC 6594 for SSHFP

[BIND 10 Development]

#2124: RFC 6594 for SSHFP
-------------------------------------+-------------------------------------
                   Reporter:         |                 Owner:  jinmei
  vorner                             |                Status:  reviewing
                       Type:         |             Milestone:
  defect                             |  Sprint-20120731
                   Priority:         |            Resolution:
  medium                             |             Sensitive:  0
                  Component:         |           Sub-Project:  DNS
  libdns++                           |  Estimated Difficulty:  2
                   Keywords:         |           Total Hours:  0
            Defect Severity:  N/A    |
Feature Depending on Ticket:         |
        Add Hours to Ticket:  0      |
                  Internal?:  0      |
-------------------------------------+-------------------------------------
Changes (by muks):

 * owner:  muks => jinmei


Comment:

 Replying to [comment:11 jinmei]:
 > - I suspect it now allows >255 textual values.  We need test cases for
 >   them, and hey should be rejected correctly.

 True. Added. :)

 > - I'd add tests for the "from wire" cases (against some uncommon
 >   algorithms/types)

 Done. :)

 > - We need a changelog for this fix.

 How does this look:
 {{{
 +XXX.   [bug]           muks
 +       SSHFP's algorithm and fingerprint type checks have been relaxed
 +       such that they will accept any values in [1,255]. This is so that
 +       future algorithm and fingerprint types are accomodated.
 +       (Trac #2124, git ...)
 +
 }}}

 > - I made some (unrelated) style cleanups.
 > - I'd make lines like this shorter:
 > {{{#!cpp
 >     EXPECT_NO_THROW(const generic::SSHFP rdata_sshfp("0 1
 123456789abcdef67890123456789abcdef67890"));
 > }}}
 >   So they won't be too long or we won't have to fold them.  For the
 >   purpose of the test, the fingerprint should be as simple as "1234"
 >   etc.

 Done. :)

 > - I'm not sure if this change is a good one:
 > {{{#!diff
 > -    EXPECT_THROW(const generic::SSHFP rdata_sshfp("1 2 foo bar"),
 InvalidRdataText);
 > +    EXPECT_THROW(const generic::SSHFP rdata_sshfp("1 2 foo bar"),
 isc::BadValue);
 > }}}
 >   In some sense it makes sense as it correctly catches what the test
 >   intends to catch (the bad part is "foo bar", and the hex decoder
 >   throws BadValue).  But from the caller's point of view, it should be
 >   more convenient and consistent if any bogus textual input generally
 >   results in `InvalidRdataText`.  In that sense I guess the better fix
 >   is to catch `BadValue` from `decodeHex()` and convert it to
 >   `InvalidRdataText`.

 Fixed. :)

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