[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: concerning tor bug report #1026
On Tue, 7 Jul 2009 13:51:53 +0200 Sebastian Hahn <mail@xxxxxxxxxxxxxxxxx>
wrote:
>On Jul 7, 2009, at 8:24 AM, Scott Bennett wrote:
>> I submitted tor bug report #1026 via Jon =
><scream@xxxxxxxxxxxxxxxxxx=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 *
**********************************************************************