concerning tor bug report #1026

[Scott Bennett]

     On Tue, 7 Jul 2009 13:51:53 +0200 Sebastian Hahn <mail at sebastianhahn.net>
wrote:
>On Jul 7, 2009, at 8:24 AM, Scott Bennett wrote:
>>     I submitted tor bug report #1026 via Jon =
><scream at nonvocalscream.com=20
>> >,
>> who volunteered to post it to bugs.torproject.org for me because =20
>> that web
>> site refuses to log me in.  (Should I write up a bug report on that, =20=
>
>> too?)
>> The report has since accumulated two comments, one on Saturday by =20
>> Karsten
>> Loesing and one on Monday by Roger Dingledine.  I address their =20
>> comments
>> here because I am unable to do so on the web site.
>
>I assume by Karsten you mean Sebastian :-)

     Yes, I see the mistake now.  My apologies.  I was still thinking about
the "Last edited by" field at the top of the report. :-(
>
>>     Karsten and Roger, there seems to be some confusion over the way =20=
>
>> the
>> bug report is listed in its indexed information.  I do not know why =20=
>
>> it is
>> listed as a tor client bug when it clearly should be listed as a tor
>> relay (a.k.a. "server") bug (likewise for #996).  I cannot account =20
>> either
>> for the severity and priority rankings for either #1026 or #996.  The
>> version in the title of #1026 (0.2.1.15-rc) is the correct version for
>> which the symptoms are being reported, not 0.2.0.35 as shown in the
>> indexed information as the "Reported Version".
>
>Yes, the bug was reported using different settings than what you have =20=
>
>reported, however, I was fully aware that this is a relay bug and that =20=
>
>the version is 0.2.1.15-rc.

     Okay.  From Roger's comment, I wasn't sure.  In any case, it is *not*
an old report.  This happened late last week, Thursday, IIRC.
>
>>     I would like to reiterate that the bug is not a bug in the =20
>> authority
>> functions of tor, but rather a bug in the relay descriptor-updating
>> functions of tor.  Nothing but the date+timestamp was changed in the =20=
>
>> new
>> descriptor update sent to the authorities, but it was sent much =20
>> earlier
>> than the normal time for the ~18-hourly update, so the relay *SHOULD =20=
>
>> NOT*
>> have sent the update in the first place.  That is the whole point.
>
>This is more curious, and explains how I misread the first version of =20=
>
>the bugreport. I see the problem now, see explanation in the bugreport =20=
>
>once I get around to updating it.

     Yes, I see your comment.  However, if the decision is to go with making
the relay (not client) recognize that the authorities didn't take the update,
then the ~18-hour timer should *not* be changed from its setting before the
failed attempt to update.  18 hours from the previous publication time will
be soon enough, at least in this situation, right?
     I am approaching the conclusion that there may be quite a few ways in
which relays may be incorrectly dropped from the consensus and that it may
take a while to pin each of them down. :-)


                                  Scott Bennett, Comm. ASMELG, CFIAG
**********************************************************************
* Internet:       bennett at cs.niu.edu                              *
*--------------------------------------------------------------------*
* "A well regulated and disciplined militia, is at all times a good  *
* objection to the introduction of that bane of all free governments *
* -- a standing army."                                               *
*    -- Gov. John Hancock, New York Journal, 28 January 1790         *
**********************************************************************