BIND 10 #955: xfrin should check TSIG before other part of incoming message

BIND 10 Development do-not-reply at isc.org
Thu Jun 9 11:41:02 UTC 2011


#955: xfrin should check TSIG before other part of incoming message
-------------------------------------+-------------------------------------
                   Reporter:         |                 Owner:  jinmei
  jinmei                             |                Status:  reviewing
                       Type:         |             Milestone:
  defect                             |  Sprint-20110614
                   Priority:  major  |            Resolution:
                  Component:  xfrin  |             Sensitive:  0
                   Keywords:         |           Sub-Project:  DNS
            Defect Severity:  N/A    |  Estimated Difficulty:  0.0
Feature Depending on Ticket:         |           Total Hours:  0
        Add Hours to Ticket:  0      |
                  Internal?:  0      |
-------------------------------------+-------------------------------------
Changes (by zzchen_pku):

 * owner:  zzchen_pku => jinmei


Comment:

 Replying to [comment:10 jinmei]:
 > Not really.  We can still check whether the exception error message is
 > the expected one (and I think we should).  In general, when we wanted
 > to say "we don't need a test for this case", we should re-think at
 > least three times if it's really, really true.  IMO in many cases it's
 > not (and, often, embarrassingly, there's a bug that could be
 > identifiable via tests).
 Okay, I have added check for error message.
 > And, this remind me of another issue I've been having with xfrin and
 > xfrout: they use the same single exception in so many places,
 > obscuring the accuracy of test results.  When we do
 > self.assertRaises(XfrinException, xxx), we cannot really be sure if
 > the exception is really triggered at where it should be triggered.  We
 > could check the exception error message as I said above, but since the
 > error message tends to be modified it will be unstable.  I guess we'll
 > need a higher granularity of exceptions (or sub types of them) for
 > these apps.  But I understand that's beyond the scope of this ticket.
 Agree, can you create ticket for it?

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


More information about the bind10-tickets mailing list