Re: [tor-bugs] #31356 [Core Tor/Tor]: 0.4.1 relays should list Padding=1, 2

[Tor Bug Tracker & Wiki]

#31356: 0.4.1 relays should list Padding=1,2
-+
 Reporter:  mikeperry|  Owner:  (none)
 Type:  defect   | Status:  needs_review
 Priority:  Medium   |  Milestone:  Tor: 0.4.1.x-final
Component:  Core Tor/Tor |Version:  Tor: 0.4.0.5
 Severity:  Normal   | Resolution:
 Keywords:  wtf-pad, 041-should  |  Actual Points:
Parent ID:   | Points:  1
 Reviewer:   |Sponsor:  Sponsor2
-+

Comment (by teor):

 Replying to [comment:8 mikeperry]:
 > I think we should keep this simple, so that it can get in before
 0.4.1-stable, with low risk. We do not support alphas once the stable is
 released.

 You're right, that's a new policy that I hadn't quite caught up with.

 > This means that we can just bump the protover without doing all of the
 extra effort to phase out Padding=1 in stages.
 >
 > In other words: if this gets merged before 0.4.1-stable, then once
 0.4.1-stable is released, it won't matter that our older 0.4.1 alpha
 clients won't negotiate with newer 0.4.1 relays -- they are unsupported.
 Similarly, it doesn't matter if 0.4.1-stable clients won't negotiate with
 0.4.1-alpha relays -- those relays are also unsupported.

 We don't need to keep Padding=1 working in alphas, so it is much simpler
 to just bump the protover. (That's different to what we discussed in the
 meeting and in #tor-dev, but I agree with you now. We're not taking
 support away from a stable release, and no-one should be relying on the
 alpha behaviour.)

 > Here is a cleanly organized PR against 0.4.1 that passes CI and is now
 actually ready for review: https://github.com/torproject/tor/pull/1230
 >
 > FTR: I didn't call you crazy. I called this entire situation crazy
 (which I meant to include my response). I meant "crazy" in the sense that
 what we were doing did not make sense to me and made things confusing to
 others. The thing that upset me was that I am capable of viewing the CI
 logs of PRs that I'm still actively rebasing and re-organizing.. I didn't
 need those logs to occupy space in this ticket, and I didn't want them to,
 which is why I didn't ask anyone to review it or even mention the branch
 yet.. That said, I should have reacted more reasonably myself rather than
 mirroring and exaggerating what I felt were unreasonable actions, which is
 a bad habit of mine that I have been trying to break. It was the end of a
 long week.

 Thanks for this explanation. I am also trying to react less to situations
 which stress me out.

 Here's how I'd like a conversation like this to go in future:

 teor: does something unnecessary
 mikeperry: Please don't do that thing. Can I delete your comment?
 teor: Oops sorry. Of course! I will try to remember next time.

 I am going to edit my comment with the logs to reduce the space it takes
 up.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #31356 [Core Tor/Tor]: 0.4.1 relays should list Padding=1, 2

[Tor Bug Tracker & Wiki]

#31356: 0.4.1 relays should list Padding=1,2
-+
 Reporter:  mikeperry|  Owner:  (none)
 Type:  defect   | Status:  needs_review
 Priority:  Medium   |  Milestone:  Tor: 0.4.1.x-final
Component:  Core Tor/Tor |Version:  Tor: 0.4.0.5
 Severity:  Normal   | Resolution:
 Keywords:  wtf-pad, 041-should  |  Actual Points:
Parent ID:   | Points:  1
 Reviewer:   |Sponsor:  Sponsor2
-+
Changes (by mikeperry):

 * status:  needs_revision => needs_review


Comment:

 I think we should keep this simple, so that it can get in before
 0.4.1-stable, with low risk. We do not support alphas once the stable is
 released. This means that we can just bump the protover without doing all
 of the extra effort to phase out Padding=1 in stages.

 In other words: if this gets merged before 0.4.1-stable, then once
 0.4.1-stable is released, it won't matter that our older 0.4.1 alpha
 clients won't negotiate with newer 0.4.1 relays -- they are unsupported.
 Similarly, it doesn't matter if 0.4.1-stable clients won't negotiate with
 0.4.1-alpha relays -- those relays are also unsupported.

 Here is a cleanly organized PR against 0.4.1 that passes CI and is now
 actually ready for review: https://github.com/torproject/tor/pull/1230

 FTR: I didn't call you crazy. I called this entire situation crazy (which
 I meant to include my response). I meant "crazy" in the sense that what we
 were doing did not make sense to me and made things confusing to others.
 The thing that upset me was that I am capable of viewing the CI logs of
 PRs that I'm still actively rebasing and re-organizing.. I didn't need
 those logs to occupy space in this ticket, and I didn't want them to,
 which is why I didn't ask anyone to review it or even mention the branch
 yet.. That said, I should have reacted more reasonably myself rather than
 mirroring and exaggerating what I felt were unreasonable actions, which is
 a bad habit of mine that I have been trying to break. It was the end of a
 long week.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #31356 [Core Tor/Tor]: 0.4.1 relays should list Padding=1, 2

[Tor Bug Tracker & Wiki]

#31356: 0.4.1 relays should list Padding=1,2
-+
 Reporter:  mikeperry|  Owner:  (none)
 Type:  defect   | Status:  needs_revision
 Priority:  Medium   |  Milestone:  Tor: 0.4.1.x-final
Component:  Core Tor/Tor |Version:  Tor: 0.4.0.5
 Severity:  Normal   | Resolution:
 Keywords:  wtf-pad, 041-should  |  Actual Points:
Parent ID:   | Points:  1
 Reviewer:   |Sponsor:  Sponsor2
-+

Comment (by teor):

 The client change is #31387.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #31356 [Core Tor/Tor]: 0.4.1 relays should list Padding=1, 2 (was: 0.4.0 relays should not list Padding=1)

[Tor Bug Tracker & Wiki]

#31356: 0.4.1 relays should list Padding=1,2
-+
 Reporter:  mikeperry|  Owner:  (none)
 Type:  defect   | Status:  needs_revision
 Priority:  Medium   |  Milestone:  Tor: 0.4.1.x-final
Component:  Core Tor/Tor |Version:  Tor: 0.4.0.5
 Severity:  Normal   | Resolution:
 Keywords:  wtf-pad, 041-should  |  Actual Points:
Parent ID:   | Points:  1
 Reviewer:   |Sponsor:  Sponsor2
-+
Changes (by teor):

 * status:  needs_review => needs_revision
 * keywords:  wtf-pad => wtf-pad, 041-should
 * milestone:   => Tor: 0.4.1.x-final


Old description:

> Somehow we accidentally merged the protover for padding support while
> doing the incremental merge thing, and 0.4.0 relays are advertising
> padding that they don't support. This is mostly harmless, because the
> negotiation will not succeed and then clients will stop, but it will
> result in those clients emitting a "Middle node did not accept our
> padding request" protocol warn/info message.
>
> We should just remove this protover field from 0.4.0.x.

New description:

 Somehow we accidentally merged the protover for padding support while
 doing the incremental merge thing, and 0.4.0 relays are advertising
 padding that they don't support. This is mostly harmless, because the
 negotiation will not succeed and then clients will stop, but it will
 result in those clients emitting a "Middle node did not accept our padding
 request" protocol warn/info message.

 ~~We should just remove this protover field from 0.4.0.x.~~

 At the weekly meeting last week, we decided that we can't remove a
 protover once it's been released.
 Instead, we will:
 * make 0.4.1 and later relays declare Padding=1,2 (pre-0.4.1 stable)
 * make 0.4.1 and later clients require Padding=2 (padding is not on by
 default, so we can do this at any time)

--

Comment:

 At the weekly meeting last week, we decided that we can't remove a
 protover once it's been released. See the ticket description for details.
 I'll open another ticket for the client change.

 Mike, I'm happy to do this change, if that would help you with your work
 overload.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs