Opened 8 months ago

Last modified 5 months ago

#32672 merge_ready task

Reject 0.2.9 and 0.4.0 in dirserv_rejects_tor_version()

Reported by: teor Owned by: neel
Priority: Medium Milestone: Tor: 0.4.2.x-final
Component: Core Tor/Tor Version:
Severity: Normal Keywords: 044-should, 043-backport, 041-backport, 042-backport, consider-backport-after-authority-test, fast-fix, network-health
Cc: dgoulet, gk, neel, arma, ggus, phw Actual Points:
Parent ID: Points: 0.5
Reviewer: teor Sponsor:

Description

We should modify dirserv_rejects_tor_version() to keep it up to date with our supported versions:

  • After 1 January 2020, we should reject all versions less than 0.3.5.
  • After 2 February 2020, we should reject the 0.4.0 series, but allow the 0.3.5 series

https://trac.torproject.org/projects/tor/wiki/org/teams/NetworkTeam/CoreTorReleases#Current

After these dates, we should get arma to test this change, then merge it.

After we merge, we should create a ticket in 0.4.4 to reject 0.4.1.

Child Tickets

Attachments (6)

ticket32672_contacts_20200219.txt (66.8 KB) - added by gk 6 months ago.
ticket32672_per_contact_20200219.txt (51.1 KB) - added by gk 6 months ago.
bug32672_emailed_20200225.txt (50.8 KB) - added by gk 5 months ago.
bug32672_control_20200305.txt (34.8 KB) - added by gk 5 months ago.
bug32672_in_emailed_but_not_control.txt (4.3 KB) - added by gk 5 months ago.
old_bridges.py (1.2 KB) - added by phw 5 months ago.
Tool to identify old bridges in bridge-descriptors.

Download all attachments as: .zip

Change History (53)

comment:1 Changed 8 months ago by arma

Cc: dgoulet gk added
Keywords: network-health added

dgoulet/gk/somebody, can you get us a set of currently running relays and contactinfos, maybe sorted like last time, so we can go through and contact these relays asap?

comment:2 Changed 8 months ago by teor

Nothing is broken on these relays, yet. But you're right, we should encourage them to upgrade. There are still ~650 relays on 0.2.9, and maybe 100 on 0.4.0.

comment:3 Changed 8 months ago by neel

Owner: set to neel
Status: newassigned

Assigning this to myself.

comment:4 Changed 8 months ago by neel

Status: assignedneeds_review

comment:5 Changed 8 months ago by neel

Cc: neel added

comment:6 Changed 8 months ago by teor

Keywords: teor-backlog removed
Reviewer: teor
Status: needs_reviewneeds_revision

Thanks, just a few fixes needed:

  1. fix a comment to explain what happened to 0.3.6.0-alpha-dev
  2. add tests for current releases
  3. work out if we want to reject 0.4.0 alphas and rcs. To do that, we need to check how many there are in the network.
  4. Rebase on 0.4.1, because we might backport this branch to 0.4.1

Once we've made these changes, we should email all the affected operators, and then test this patch on moria1. After we've done both those things, we can merge.

comment:7 Changed 8 months ago by neel

Status: needs_revisionneeds_review

Rebasing this branch over 0.4.1 doesn't make sense, as the tests are missing on that branch. However, I have a secondary PR for 0.4.1.

About blocking 0.4.1 alphas/rc, I would be against it unless there is a crippling bug on the 0.4.1 alphas/rc releases. For instance, 0.2.9.5-rc is allowed on the network because it "works" (may not be the most secure, but technically works), whereas 0.2.9.4 and below have a consensus bug.

The changes are posted to both the original PR based off master and the 0.4.1 PR here: https://github.com/torproject/tor/pull/1588

I don't know if two PRs will work for you, but here it is.

comment:8 in reply to:  7 Changed 8 months ago by teor

Status: needs_reviewneeds_information

Replying to neel:

About blocking 0.4.1 alphas/rc, I would be against it unless there is a crippling bug on the 0.4.1 alphas/rc releases. For instance, 0.2.9.5-rc is allowed on the network because it "works" (may not be the most secure, but technically works), whereas 0.2.9.4 and below have a consensus bug.

Yes, we decided to keep 0.2.9.5-rc, when we made a decision about 0.2.9.

But recently, when we made a decision about 0.3.5, we rejected unstable versions of 0.3.5 because those versions are not supported. (And there were not many relays on those versions.)
https://github.com/torproject/tor/pull/1588/files#diff-c535b81e06d7fed27d5d3cdaabf1c4b8R331

Unless there is some compelling reason to keep 0.4.0 unstable relays, we should encourage their operators to upgrade.

The changes are posted to both the original PR based off master and the 0.4.1 PR here: https://github.com/torproject/tor/pull/1588

I don't know if two PRs will work for you, but here it is.

We normally do backports with multiple PRs. Because of the way that git does merges, the best way to get a good merge is to do the common changes in one commit, and the extra changes for later versions in other commits. You won't need to do that here, this patch is small enough that we can resolve any merge conflicts ourselves.

To move forward with this ticket, we need to:

  • find out how many relays are on unstable 0.4.0 versions
  • decide if we want to reject those versions

comment:9 Changed 8 months ago by dgoulet

After 1 January 2020, we should reject all versions less than 0.3.5.

Latest consensus:

<= 0.3.5 series: 781 [w: 6.53%]

Distribution:

  16: 0.2.4             [0.02 %] (MAJOR)
  14: 0.2.5             [0.21 %] (MAJOR)
   2: 0.2.6             [0.00 %] (MAJOR)
   2: 0.2.7             [0.09 %] (MAJOR)
   2: 0.2.8             [0.00 %] (MAJOR)
 640: 0.2.9             [5.48 %] (MAJOR)
  12: 0.3.0             [0.00 %] (MAJOR)
   3: 0.3.1             [0.00 %] (MAJOR)
  23: 0.3.2             [0.15 %] (MAJOR)
   8: 0.3.3             [0.05 %] (MAJOR)
  59: 0.3.4             [0.54 %] (MAJOR)

find out how many relays are on unstable 0.4.0 versions

0.4.0 series: 520 [w: 11.23%]

Distribution:

   1: 0.4.0.0-alpha-dev [0.00 %] 
   2: 0.4.0.1-alpha     [0.08 %] 
   1: 0.4.0.1-alpha-dev [0.00 %] 
   3: 0.4.0.2-alpha     [0.19 %] 
   2: 0.4.0.3-alpha     [0.01 %] 
   1: 0.4.0.4-rc        [0.02 %] 
 509: 0.4.0.5           [10.89 %] 
   1: 0.4.0.6           [0.04 %] 

comment:10 Changed 8 months ago by teor

Thanks dgoulet, looks like we need to contact operators on 0.3.4 and earlier, and 0.4.0, particularly 0.2.9 and 0.4.0.5.

There was a typo in my last post, we are actually talking about rejecting unstable 0.4.1 versions, as well as all of 0.4.0.

How many relays are on 0.4.1 unstable?

comment:11 Changed 8 months ago by gk

It seems like 9 if I understand the output correctly:

   2: 0.4.1.2-alpha     [0.02 %] 
   5: 0.4.1.3-alpha     [0.07 %] 
   2: 0.4.1.4-rc        [0.00 %] 

comment:12 in reply to:  11 Changed 8 months ago by dgoulet

Replying to gk:

It seems like 9 if I understand the output correctly:

   2: 0.4.1.2-alpha     [0.02 %] 
   5: 0.4.1.3-alpha     [0.07 %] 
   2: 0.4.1.4-rc        [0.00 %] 

Correct. I see the same.

comment:13 Changed 8 months ago by teor

Status: needs_informationneeds_revision

I think it is a good idea to exclude 9 relays, so we avoid any bugs in unstable 0.4.1 on the network.

Neel, please also reject 0.4.1.0-alpha-dev to 0.4.1.4-rc.

comment:14 Changed 8 months ago by neel

Status: needs_revisionneeds_review

Made the changes and pushed them.

comment:15 Changed 8 months ago by teor

Cc: arma added
Status: needs_reviewmerge_ready

Thanks, this looks good. Here's what we need to do now:

  1. email all the affected operators, and ask them to upgrade
  2. test this patch on moria1
  3. squash the fixup commits
  4. rebase the master patch to 0.4.2
  5. merge and merge forward:
  6. deploy to the other directory authorities

We can merge before testing, if that's helpful for arma.

comment:16 Changed 8 months ago by dgoulet

I've compiled the list of relays that have a ContactInfo (might not be valid) that matches the version we are wanting to reject. Can be found here:

https://people.torproject.org/~dgoulet/volatile/ticket32672_contacts.txt

(Sorted by bandwidth weight)

comment:17 Changed 8 months ago by nickm

Summary: Reject 0.2.9 and 0.4.0 in dirserv_rejects_tor_version()Reject 0.2.9 and 0.4.0 in dirserv_rejects_tor_version() [DO NOT MERGE BEFORE 2020]

Changing title to reduce the odds of an accidental early merge.

comment:18 Changed 7 months ago by nickm

Keywords: 043-should, 041-backport, 042-backport, consider-backport-after-authority-test, fast-fix, network-health043-should, 041-backport, 042-backport, consider-backport-after-authority-test, fast-fix, network-health 043-should

comment:19 Changed 7 months ago by teor

Summary: Reject 0.2.9 and 0.4.0 in dirserv_rejects_tor_version() [DO NOT MERGE BEFORE 2020]Reject 0.2.9 and 0.4.0 in dirserv_rejects_tor_version() [DO NOT MERGE BEFORE FEB 2020]

The merge should happen on or after 2 February 2020.

comment:20 Changed 7 months ago by nickm

Keywords: 044-should 043-backport added
Milestone: Tor: 0.4.3.x-finalTor: 0.4.4.x-final

I'm thinking this is better for the 0.4.4 timeline.

comment:21 Changed 6 months ago by nusenu

related: #33130

comment:22 Changed 6 months ago by teor

Keywords: 043-should removed

comment:23 Changed 6 months ago by teor

Summary: Reject 0.2.9 and 0.4.0 in dirserv_rejects_tor_version() [DO NOT MERGE BEFORE FEB 2020]Reject 0.2.9 and 0.4.0 in dirserv_rejects_tor_version()

Hi Nick,

0.4.4 is open now, and 0.2.9 and 0.4.0 are no longer recommended versions (#33130, about 2 weeks ago).

Do you think it's time to merge this change into master?

comment:24 Changed 6 months ago by nickm

I'd like sign-off from arma and/or gk (in his role as network health lead) before going ahead with this: arma usually likes to double-check how much of the network we're about to lose.

comment:25 Changed 6 months ago by gk

We should look a bit at the data first and try to reach (again) affected operators.

nickm: assuming we want to have this in 0.4.4, what is the latest date we need to make a decision here (not taking into account that the new 0.4.4/older versions with a backported patch need to get released and deployed first)? (That is: how much time do we have left to think about the potential impact on relay bandwidth/diversity etc. and try different means to reach affected operators?)

comment:26 Changed 6 months ago by gk

Attached is the output of a new script run compared to what dgoulet did in comment:16 about two months ago. Relays are included if they are running 0.2.9.x or 0.4.0.x or 0.3.y (y != 5) AND have some kind of ContactInfo. (It seems the entries to consider went down from about 680 to around 400 compared to the previous run, which is great)

I am working on a next iteration of the output that removes all the duplicated ContactInfo entries so we get a better list of whom to contact and an understanding of how large that contact effort would be and where the low-hanging fruits were (depending on how we would like to proceed).

Meanwhile, one thing to think about is whether we want to treat 0.2.9 and 0.4.0 differently or what criteria for treating them differently could be. That is, speaks there anything for, say, keeping 0.4.0 around for a bit longer while rejecting 0.2.9 asap (or vice versa)?

Changed 6 months ago by gk

comment:27 Changed 6 months ago by teor

The last release of 0.2.9 was 13 months ago. Even before then, we didn't backport all our fixes to 0.2.9. And there have been no new features in 0.2.9 for 3-4 years.

0.4.0's last release was a month or two ago, it's reasonably up-to-date.

If we patch any security issues, we won't patch 0.2.9 or 0.4.0. If we decide that a security fix is required, we might need to reject them straight after the release of that fix. We don't really control the timing of security fixes.

This ticket is a directory authority change. We don't support directory authorities older than the last two stable releases. That's 0.4.1 right now, and it will be 0.4.2 by the time 0.4.4 is in feature freeze.

Feature freeze for 0.4.2 is May 15 2020:
https://trac.torproject.org/projects/tor/wiki/org/teams/NetworkTeam/CoreTorReleases#Current

Last edited 6 months ago by teor (previous) (diff)

comment:28 in reply to:  26 Changed 6 months ago by gk

Cc: ggus added

Replying to gk:

Attached is the output of a new script run compared to what dgoulet did in comment:16 about two months ago. Relays are included if they are running 0.2.9.x or 0.4.0.x or 0.3.y (y != 5) AND have some kind of ContactInfo. (It seems the entries to consider went down from about 680 to around 400 compared to the previous run, which is great)

I am working on a next iteration of the output that removes all the duplicated ContactInfo entries so we get a better list of whom to contact and an understanding of how large that contact effort would be and where the low-hanging fruits were (depending on how we would like to proceed).

Okay, attached is a new version that is down to essentially 276 entries (we know the situation of the smell relays and I got the DFRI folks to upgrade their relays meanwhile, in addition to an operator who was previously on 0.4.0.5 and is still there in my previous attachment), weighted by bw (I added the bw of all relays per ContactInfo in case there is more than one relay but did not bother to show all fingerprints involved).

We could now think about grepping for the fingerprints and start taking a random number from the top and contact the operators. I am waiting for ggus here so we can coordinate.

Changed 6 months ago by gk

comment:29 Changed 6 months ago by nickm

Gk asks:

nickm: assuming we want to have this in 0.4.4, what is the latest date we need to make a decision here (not taking into account that the new 0.4.4/older versions with a backported patch need to get released and deployed first)? (That is: how much time do we have left to think about the potential impact on relay bandwidth/diversity etc. and try different means to reach affected operators?)

Our feature freeze date for 0.4.4 is May 15, but I would like to have these versions off the network sooner than that if we can.

I think we should aim to contact the affected relay operators soon, and measure what effect that has. If it helps, we can try doing it more -- but it may be that we don't see much effect, and the right thing to do is just to disable these versions.

Teor notes:

If we patch any security issues, we won't patch 0.2.9 or 0.4.0. If we decide that a security fix is required, we might need to reject them straight after the release of that fix. We don't really control the timing of security fixes.

Right, and the kind of security bug that we run into is important. If (heaven forbid) we find an RCE issue, or a memory exposure issue, we'll need everybody to upgrade asap, with no delays, and no excuses. If we run into a remote crash or CPU DoS issue, then we still want everybody to upgrade, since the issue would have potential to make traffic analysis easier, but it wouldn't be under as much time pressure as a critical-severity issue would be.

comment:30 Changed 6 months ago by nickm

So, looking at historical migration curves for older deprecated releases, it seems like if we did anything that had a major effect in making people upgrade, the effect was fairly abrupt -- like, within the space of a week. So this would imply that we don't need to do a long experiment here: ideally, we send out a large first batch of emails, and see whether they have a measurable effect within a week or two. If they do, we can email everybody else and wait another week or two, then deploy this patch.

(I'd suggest maybe doing some kind of a randomized trial here, if you have the time and energy.)

comment:31 Changed 6 months ago by teor

We need to check if this patch affects bridges. As far as I recall, the last patch affected bridges as well as relays.

comment:32 in reply to:  31 Changed 6 months ago by dgoulet

Replying to teor:

We need to check if this patch affects bridges. As far as I recall, the last patch affected bridges as well as relays.

It does. This is called around a authdir_mode() and thus affects Bridge and Directory authorities.

It is called basically when we load the fingerprints from the approved router list and when we consider descriptors to vote on. Both are looking at AuthoritativeDir.

comment:33 Changed 6 months ago by ggus

I am waiting for ggus here so we can coordinate.

Hi, yesterday I contacted organizations and relay operators from Brazil, Chile, Mexico, Costa Rica. I sent localized email in Spanish and Portuguese, some people replied and upgraded their relays.

GeKo, we could select relay operators from two or three countries, and contact them today (Friday) or Wednesday. I'll be offline next Monday and Tuesday, so I can't follow up if they have questions.

And here's Roger email that we can use:

Hi,

You are running a Tor relay, which is great:
http://rougmnvswfsmd4dq.onion/rs.html#details/$fingerprint

But that Tor version is obsolete, and because of old bugs, we will soon
cut relays running those versions out of the network. Please consider
upgrading!

You can find Tor packages and instructions for your distro / OS here:
https://community.torproject.org/relay/setup/guard/

Ideally you will switch to keeping up with our stable releases, but if
you need a stable that is especially stable, the Tor 0.3.5 branch will
be maintained until Feb 2022:
https://trac.torproject.org/projects/tor/wiki/org/teams/NetworkTeam/CoreTorReleases#Current
and you can see the lifetimes of other Tor versions on that table too.

Let us know if we can do anything to make the process easier.

And lastly, I am cc'ing the new network health mailing list (which
has public archives), to help us stay synced:
https://trac.torproject.org/projects/tor/wiki/org/teams/NetworkHealthTeam

Thanks!
--$name
Last edited 6 months ago by ggus (previous) (diff)

comment:34 Changed 5 months ago by nusenu

https://lists.torproject.org/pipermail/tor-relays/2020-February/018185.html

Running relays and consensus weight fraction as of 2020-02-23 10:00 UTC

+-------------+------+---------+
| tor_version | cwfr | #relays |
+-------------+------+---------+
| 0.4.0.x     | 2.45 |     114 |
| 0.2.9.x     | 1.44 |     265 |
+-------------+------+---------+
Last edited 5 months ago by nusenu (previous) (diff)

comment:35 Changed 5 months ago by gk

Okay, I am done sending mails. I guess we can collect some stats next week and maybe in two weeks to figure out how the mailing went.

That's just for relays, though. I don't have access to addresses of bridge operators.

Changed 5 months ago by gk

Changed 5 months ago by gk

comment:36 Changed 5 months ago by gk

Alright, I attached the file containing all the relay operators with relays running obsolete Tor versions we want to reject (that's from last week). Additionally, I attached another file showing the remaining operators on those versions, a bit more than a week after the email campaign.

We can see that the amount got reduced by 1/3 which is encouraging, even though I have not made a detailed analysis yet whether the operators actually migrated to newer versions or shut them down or... Interestingly, though, the sum of the bandwidth shown for the relays in both files *rose*. I have not looked as to why this happened.

Some explanations to the annotations I made on the file I used for sending the emails:

"[x]" means I sent an email successfully.
"[xf]" means I sent an email but I got an error back.
"[xfam]" means I sent an email and asked to set MyFamily properly while I was at it.
"[f due to $]" means I did not send an email due to $.

Additionally, you'll see that I changed my strategy for sending mails to the operators during the whole process: First, I send the email and Cc'ed the network-health list without any Reply-To header. Then I did the same with Reply-To header set to the mailing list. Then I only Cc'ed the list with the proper Reply-To header if the email address was not obfuscated. And then due to complaints by folks subscribed to the list I sent the last batch of mails without Cc'ing the network-health.

comment:37 Changed 5 months ago by ggus

Cc: phw added

Hi phw, could you reach out to Bridges operators?

comment:38 Changed 5 months ago by gk

Here is the current bridge situation looking at the bridge descriptors:

== Bridges == 
 401: 0.2.9             [2.20 %] (MAJOR)
  14: 0.2.9.10          [0.10 %] 
  16: 0.2.9.11          [0.06 %] 
   2: 0.2.9.12          [0.00 %] 
   9: 0.2.9.13          [0.02 %] 
  61: 0.2.9.14          [0.22 %] 
  10: 0.2.9.15          [0.03 %] 
 219: 0.2.9.16          [1.39 %] 
  67: 0.2.9.17          [0.37 %] 
   3: 0.2.9.9           [0.01 %] 
2106: 0.3.5             [18.82 %] (MAJOR)
  68: 0.3.5.7           [1.34 %] 
2031: 0.3.5.8           [17.29 %] 
   7: 0.3.5.9           [0.19 %] 
   1: 0.3.6             [0.00 %] (MAJOR)
   1: 0.3.6.0-alpha-dev [0.00 %] 
 186: 0.4.0             [4.55 %] (MAJOR)
   1: 0.4.0.0-alpha-dev [0.00 %] 
   1: 0.4.0.1-alpha-dev [0.00 %] 
   1: 0.4.0.2-alpha     [0.05 %] 
   1: 0.4.0.4-rc        [0.02 %] 
 176: 0.4.0.5           [4.12 %] 
   6: 0.4.0.6           [0.36 %] 
 883: 0.4.1             [11.08 %] (MAJOR)
   2: 0.4.1.3-alpha     [0.01 %] 
   1: 0.4.1.4-rc        [0.00 %] 
 134: 0.4.1.5           [1.70 %] 
 638: 0.4.1.6           [8.32 %] 
 107: 0.4.1.7           [1.04 %] 
   1: 0.4.1.8           [0.01 %] 
3587: 0.4.2             [59.59 %] (MAJOR)
   2: 0.4.2.0-alpha-dev [0.00 %] 
   1: 0.4.2.1-alpha     [0.00 %] 
   1: 0.4.2.1-alpha-dev [0.00 %] 
   1: 0.4.2.2-alpha-dev [0.01 %] 
   3: 0.4.2.3-alpha     [0.06 %] 
  17: 0.4.2.4-rc        [0.24 %] 
   2: 0.4.2.4-rc-dev    [0.00 %] 
 973: 0.4.2.5           [16.00 %] 
   1: 0.4.2.5-dev       [0.00 %] 
2585: 0.4.2.6           [43.26 %] 
   1: 0.4.2.6-dev       [0.01 %] 
 116: 0.4.3             [2.74 %] (MAJOR)
  10: 0.4.3.0-alpha-dev [0.26 %] 
  33: 0.4.3.1-alpha     [0.93 %] 
   2: 0.4.3.1-alpha-dev [0.00 %] 
  69: 0.4.3.2-alpha     [1.53 %] 
   2: 0.4.3.2-alpha-dev [0.01 %] 
  37: 0.4.4             [1.02 %] (MAJOR)
  37: 0.4.4.0-alpha-dev [1.02 %] 

== Bridge - Series == 
0.2.x series: 401 [w: 2.20%]
Not supported 0.3.x series: 1 [w: 0.00%]
0.4.0.x series: 186 [w: 4.55%]

comment:39 Changed 5 months ago by gk

I added another file showing the relays not on 0.2.9.x or 0.4.0.x taken from earlier today anymore but from the consensus I used for emailing folks. The quick takeaway is the reason for them not being on my list anymore is due to either being down (that is they don't have upgraded and relay search is showing them as down OR they are not visible on relays search anymore) (26.5%) or having upgraded to 0.3.5.x (24%), or having upgraded to 0.4.x (49,4%).

I have not looked at whether the LTS folks upgraded to LTS or whether they used straight the latest stable Tor version on their platform.

Additionally, I found that a bunch of relays (10) where in the group or relays running 0.2.9.x or 0.4.0.x in today's consensus but not being present in the one last week. I mailed 8/10 of them and asked for an upgrade (2/10 did not have a usable ContactInfo set).

comment:40 Changed 5 months ago by teor

So just to confirm, we're waiting for phw to reach out to bridge operators, before merging this change?

comment:41 in reply to:  40 Changed 5 months ago by gk

Replying to teor:

So just to confirm, we're waiting for phw to reach out to bridge operators, before merging this change?

Yes. The current plan is to talk about the next steps during the network health meeting next Monday.

Changed 5 months ago by phw

Attachment: old_bridges.py added

Tool to identify old bridges in bridge-descriptors.

comment:42 Changed 5 months ago by phw

Using this tool and a bridge-descriptor file from 13 Mar 2020 07:18:51 PM UTC, I looked for bridges that run 0.4.0.* or 0.2.9.*. These are the ones we should contact, correct?

The data shows that 96 out of 1,673 (5.7%) bridges run old Tor version. Among these 96, only 52 (54.2%) have (mostly) valid contact information.

comment:43 in reply to:  42 Changed 5 months ago by teor

Replying to phw:

Using this tool and a bridge-descriptor file from 13 Mar 2020 07:18:51 PM UTC, I looked for bridges that run 0.4.0.* or 0.2.9.*. These are the ones we should contact, correct?

This patch also rejects unstable 0.3.5 versions, that is, 0.3.5.6-rc and earlier.

There aren't any relays on those versions, so there might not be any bridges, either.

The data shows that 96 out of 1,673 (5.7%) bridges run old Tor version. Among these 96, only 52 (54.2%) have (mostly) valid contact information.

Great, let's try to contact them before we merge the patch.

comment:44 Changed 5 months ago by phw

I sent 47 emails for 47 bridges to 42 operators and copied the network health mailing list. Six of these emails bounced because of non-existent mailboxes. Here's the version distribution of the 47 affected bridges:

Count Version
34 0.2.9.16
6 0.4.0.5
6 0.2.9.17
1 0.4.0.4-rc

comment:45 Changed 5 months ago by teor

Thanks phw!

I think we're ready to merge soon.

comment:46 Changed 5 months ago by nickm

I've squashed and rebased slightly. The 0.4.1 branch is ticket32672_041_squashed with PR at https://github.com/torproject/tor/pull/1799.

The 0.4.2 branch is ticket32672_042_squashed_w_test. It is made by merging the 0.4.1 branch on top of maint-0.4.2, and then applying the unit test fix as a separate patch. Its PR is https://github.com/torproject/tor/pull/1800

Having the branches based on each other in this way should help our history longterm.

Waiting for CI before merging to 0.4.3.

comment:47 Changed 5 months ago by nickm

Milestone: Tor: 0.4.4.x-finalTor: 0.4.2.x-final

Merged into 0.4.3, marking for backport.

Note: See TracTickets for help on using tickets.