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

BIND 10 Development do-not-reply at isc.org
Fri Jun 10 01:02:54 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:  2.0
Feature Depending on Ticket:         |           Total Hours:  0
        Add Hours to Ticket:  0      |
                  Internal?:  0      |
-------------------------------------+-------------------------------------

Comment (by jinmei):

 Replying to [comment:12 zzchen_pku]:
 > 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.

 Your solution is impressive:-) but I have a concern.  With this approach
 the original stdout is closed after a test, which may cause unexpectedly
 bad side effect (even if not, it's generally not good to leave a global
 side effect after a test case).  I'd suggest catching and examining
 the exception and the error message explicitly.  See the attached
 sample diff.

 We may want to generalize it and move it somewhere else so that other
 tests can use it; or this may just have to be a short term workaround
 until we solve the other generic issue (below).  In any case that will
 be beyond the scope of this ticket, so I'm okay with having it within
 xfrin for now.

 Note also that with this approach you won't need to tweak the body of
 xfrin as you did in the previous commit.

 > Agree, can you create ticket for it?

 Yes, please.

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


More information about the bind10-tickets mailing list