Directory Authorities issueshttps://gitlab.torproject.org/tpo/core/dirauth/-/issues2020-06-27T14:11:26Zhttps://gitlab.torproject.org/tpo/core/dirauth/-/issues/32869remove end-of-life tor versions 0.2.9.x from recommended versions to warn rel...2020-06-27T14:11:26Znusenuremove end-of-life tor versions 0.2.9.x from recommended versions to warn relay operatorstor 0.2.9.x reached eol on 2020-01-01 let's remove it from the list of recommended client and server versions so operators get to see a warning on Relay Search
https://consensus-health.torproject.org/#recommendedversions
```
client-ver...tor 0.2.9.x reached eol on 2020-01-01 let's remove it from the list of recommended client and server versions so operators get to see a warning on Relay Search
https://consensus-health.torproject.org/#recommendedversions
```
client-versions 0.2.9.14, 0.2.9.15, 0.2.9.16, 0.2.9.17,
0.3.5.7, 0.3.5.8, 0.3.5.9, 0.4.0.5, 0.4.0.6, 0.4.1.2-alpha, 0.4.1.3-alpha, 0.4.1.4-rc, 0.4.1.5, 0.4.1.6, 0.4.1.7, 0.4.2.1-alpha, 0.4.2.2-alpha, 0.4.2.3-alpha, 0.4.2.4-rc, 0.4.2.5
server-versions 0.2.9.15, 0.2.9.16, 0.2.9.17, 0.3.5.8, 0.3.5.9, 0.4.0.5, 0.4.0.6, 0.4.1.2-alpha, 0.4.1.3-alpha, 0.4.1.4-rc, 0.4.1.5, 0.4.1.6, 0.4.1.7, 0.4.2.1-alpha, 0.4.2.2-alpha, 0.4.2.3-alpha, 0.4.2.4-rc, 0.4.2.5
```https://gitlab.torproject.org/tpo/core/dirauth/-/issues/30533Bandwidth Unmeasured in Testing Tor Network2020-06-27T14:11:26ZTracBandwidth Unmeasured in Testing Tor NetworkI have run the Testing Tor Network based on docker, however, the bandwidth of relays in consensus is 0, and they are labeled as unmeasured.
like
```
r tor21 AXeRGqg59zZ0JOyocxlonwk84Qg zv7cbbO1TcuYfwhzA/VjeE/u9UY 2019-05-18 15:49:03 172...I have run the Testing Tor Network based on docker, however, the bandwidth of relays in consensus is 0, and they are labeled as unmeasured.
like
```
r tor21 AXeRGqg59zZ0JOyocxlonwk84Qg zv7cbbO1TcuYfwhzA/VjeE/u9UY 2019-05-18 15:49:03 172.25.0.121 5000 0
s Exit Fast Running V2Dir Valid
v Tor 0.3.5.7
pr Cons=1-2 Desc=1-2 DirCache=1-2 HSDir=1-2 HSIntro=3-4 HSRend=1-2 Link=1-5 LinkAuth=1,3 Microdesc=1-2 Relay=1-2
w Bandwidth=0 Unmeasured=1 (The bandwidth is labeled as unmeasured)
p reject 25,119,135-139,445,563,1214,4661-4666,6346-6429,6699,6881-6999
```
The torrc file of my authority server is listed as following:
```
Log info file /root/log/info.log
DisableDebuggerAttachment 0
SocksPort 0
OrPort 5000
Address 172.25.0.10
DirPort 7000
AuthoritativeDirectory 1
V3AuthoritativeDirectory 1
ContactInfo auth@test.test
ExitPolicy reject *:*
ServerDNSAllowBrokenConfig 1
DirAllowPrivateAddresses 1
EnforceDistinctSubnets 0
AssumeReachable 1
AuthDirMaxServersPerAddr 0
AuthDirMaxServersPerAuthAddr 0
ClientDNSRejectInternalAddresses 0
ClientRejectInternalAddresses 0
CountPrivateBandwidth 1
ExitPolicyRejectPrivate 0
ExtendAllowPrivateAddresses 1
V3AuthVotingInterval 5 minutes
V3AuthVoteDelay 20 seconds
V3AuthDistDelay 20 seconds
MinUptimeHidServDirectoryV2 0 seconds
TestingV3AuthInitialVotingInterval 5 minutes
TestingV3AuthInitialVoteDelay 20 seconds
TestingV3AuthInitialDistDelay 20 seconds
TestingAuthDirTimeToLearnReachability 0 minutes
TestingEstimatedDescriptorPropagationTime 0 minutes
TestingClientMaxIntervalWithoutRequest 5 seconds
TestingDirConnectionMaxStall 30 seconds
TestingEnableConnBwEvent 1
TestingEnableCellStatsEvent 1
```
The version of tor is 0.3.3.8
**Trac**:
**Username**: TBD.Chenhttps://gitlab.torproject.org/tpo/core/dirauth/-/issues/29102Serialize padding state machine in consensus2022-02-07T19:22:06ZMike PerrySerialize padding state machine in consensusWe should have the ability to list padding machines in the consensus.
This might not make 041.We should have the ability to list padding machines in the consensus.
This might not make 041.https://gitlab.torproject.org/tpo/core/dirauth/-/issues/28691dirauth longclaw network connectivity impaired2020-06-27T14:11:27Zstarlightdirauth longclaw network connectivity impairedFor quite some time the longclaw dirauth has apparently been operating with badly degraded network connectivity resulting in degraded consensus votes. Per
https://consensus-health.torproject.org/#overlap
```
Only in vote ...For quite some time the longclaw dirauth has apparently been operating with badly degraded network connectivity resulting in degraded consensus votes. Per
https://consensus-health.torproject.org/#overlap
```
Only in vote In vote and consensus Only in consensus
=============== ===================== =================
longclaw 10 Authority
3 BadExit
1 Exit 857 Exit
5 Fast 754 Fast !4857 Fast
21 Guard 453 Guard !2028 Guard
4 HSDir 476 HSDir !2952 HSDir
6472 Running !13 Running
52 Stable 5412 Stable !26 Stable
1 V2Dir 6443 V2Dir
7439 Valid
117 FallbackDir
67 Unmeasured
38 DescMismtch 0 DescMismtch
```
Of particular note longclaw marks close to 5000 relays as "not fast" compare to the consensus where other authorities see no more than about 100 as not fast w/r/t the overall consensus. A close correlation exists between "not fast" relays in longclaw's consensus and relays omitted by the SBWS scanner associated with this authority. Longclaw dirauth is not voting 2000 guard relay as such.https://gitlab.torproject.org/tpo/core/dirauth/-/issues/25121dir auths should not recommend EOL releases 0.3.0.13, 0.3.0.142020-06-27T14:11:27Zcypherpunksdir auths should not recommend EOL releases 0.3.0.13, 0.3.0.14Lets remove 0.3.0.13, 0.3.0.14 from
https://consensus-health.torproject.org/#recommendedversions
they reached eol:
https://trac.torproject.org/projects/tor/wiki/org/teams/NetworkTeam/CoreTorReleasesLets remove 0.3.0.13, 0.3.0.14 from
https://consensus-health.torproject.org/#recommendedversions
they reached eol:
https://trac.torproject.org/projects/tor/wiki/org/teams/NetworkTeam/CoreTorReleaseshttps://gitlab.torproject.org/tpo/core/dirauth/-/issues/24768Increase nf_conntimeout_clients to 5 hours2020-06-27T14:11:27ZteorIncrease nf_conntimeout_clients to 5 hoursMaybe we should experiment with making the client circuit timeout higher.
It defaults to 30 minutes. It's new in 0.3.1.
```
+#define CIRCTIMEOUT_CLIENTS_DFLT (30*60) // 30 minutes
+#define CIRCTIMEOUT_CLIENTS_MIN 60
+#define CIRCTIMEOU...Maybe we should experiment with making the client circuit timeout higher.
It defaults to 30 minutes. It's new in 0.3.1.
```
+#define CIRCTIMEOUT_CLIENTS_DFLT (30*60) // 30 minutes
+#define CIRCTIMEOUT_CLIENTS_MIN 60
+#define CIRCTIMEOUT_CLIENTS_MAX (24*60*60) // 24 hours
+ timeout = networkstatus_get_param(NULL, "nf_conntimeout_clients",
+ CIRCTIMEOUT_CLIENTS_DFLT,
+ CIRCTIMEOUT_CLIENTS_MIN,
+ CIRCTIMEOUT_CLIENTS_MAX);
```https://gitlab.torproject.org/tpo/core/dirauth/-/issues/24485Maybe found a Bad exit?2020-06-27T14:11:27ZcypherpunksMaybe found a Bad exit?Liberia 197.231.221.211 with https://bugzilla.mozilla.org/ always returns a "Secure Connection Failed"
(Sorry for putting it in the bugtracker, I don't know of any email service that allows Tor users and I don't think disposable mail se...Liberia 197.231.221.211 with https://bugzilla.mozilla.org/ always returns a "Secure Connection Failed"
(Sorry for putting it in the bugtracker, I don't know of any email service that allows Tor users and I don't think disposable mail service would be accepted in the bad-tor relays mail list)https://gitlab.torproject.org/tpo/core/dirauth/-/issues/22772lets remove tor versions vulnerable to TROVE-2017-006 from recommended versions2020-06-27T14:11:28Zcypherpunkslets remove tor versions vulnerable to TROVE-2017-006 from recommended versionsaffected: 0.3.0.1 - 0.3.0.8affected: 0.3.0.1 - 0.3.0.8https://gitlab.torproject.org/tpo/core/dirauth/-/issues/22292remove versions vulnerable to TROVE-2017-002 from "recommended versions"2020-06-27T14:11:29Zcypherpunksremove versions vulnerable to TROVE-2017-002 from "recommended versions"Roger did so already:
https://consensus-health.torproject.org/#recommendedversions
affected: 0.3.0.x before 0.3.0.7Roger did so already:
https://consensus-health.torproject.org/#recommendedversions
affected: 0.3.0.x before 0.3.0.7https://gitlab.torproject.org/tpo/core/dirauth/-/issues/21327remove versions vulnerable to TROVE-2017-001 from "recommended versions"2020-06-27T14:11:29Zcypherpunksremove versions vulnerable to TROVE-2017-001 from "recommended versions"https://consensus-health.torproject.org/#recommendedversions
vulnerable:
<0.2.9.9
<0.3.0.2-alphahttps://consensus-health.torproject.org/#recommendedversions
vulnerable:
<0.2.9.9
<0.3.0.2-alphahttps://gitlab.torproject.org/tpo/core/dirauth/-/issues/20911Why is 0.2.6.10 not a recommended version?2020-06-27T14:11:29ZteorWhy is 0.2.6.10 not a recommended version?There is no 0.2.6 series in recommended versions, but we recommend an 0.2.4, 0.2.5, and 0.2.7.
I've had a fallback operator report that they've patched their relay against TROVE-2016-10-001.
Does this have something to do with debian r...There is no 0.2.6 series in recommended versions, but we recommend an 0.2.4, 0.2.5, and 0.2.7.
I've had a fallback operator report that they've patched their relay against TROVE-2016-10-001.
Does this have something to do with debian releases, or is it just a mistake?https://gitlab.torproject.org/tpo/core/dirauth/-/issues/20896Remove 0.2.9.4-alpha as a recommended version due to stale consensus bug?2020-06-27T14:11:29ZteorRemove 0.2.9.4-alpha as a recommended version due to stale consensus bug?Should we remove 0.2.9.4-alpha as a recommended version in the consensus?
It's affected by legacy/trac#20499, which causes relays to deliver stale consensuses to clients. We should really encourage operators on this version to upgrade.Should we remove 0.2.9.4-alpha as a recommended version in the consensus?
It's affected by legacy/trac#20499, which causes relays to deliver stale consensuses to clients. We should really encourage operators on this version to upgrade.https://gitlab.torproject.org/tpo/core/dirauth/-/issues/20431do not recommend vulnerable tor versions - update "recommended versions"2020-06-27T14:11:29Zcypherpunksdo not recommend vulnerable tor versions - update "recommended versions"Most of the tor network runs versions vulnerable to CVE-2016-8860
for a current CW fraction / version distribution see:
https://github.com/ornetstats/stats/blob/master/o/version_share.txt
Dir auths still have vulnerable versions in th...Most of the tor network runs versions vulnerable to CVE-2016-8860
for a current CW fraction / version distribution see:
https://github.com/ornetstats/stats/blob/master/o/version_share.txt
Dir auths still have vulnerable versions in their recommended version string.
Drop all vulnerable version as soon as an updated TBB is available.https://gitlab.torproject.org/tpo/core/dirauth/-/issues/20089Require "p" lines in consensuses2020-06-27T14:11:30ZSebastian HahnRequire "p" lines in consensusesKarsten and I looked at the historical data, and there are no consensuses past method 5 where the p lines are omitted. Additionally, I analyzed the code. Here are my findings:
in routerstatus_format_entry(), we can either create V2 or V...Karsten and I looked at the historical data, and there are no consensuses past method 5 where the p lines are omitted. Additionally, I analyzed the code. Here are my findings:
in routerstatus_format_entry(), we can either create V2 or V3-style entries. V2 has no practical relevancy here, because the spec is for V3. For V3, we either have a consensus, a vote, a microdesc consensus, or a control port output. If we're using a method != V2, we always initialize a routerinfo_t *desc. If this step fails we do not generate an entry for this router.
Later, if desc != NULL (remember, this can only happen for V2 style documents) we call policy_summarize() and add the result as a "p" line. Looking at this function, it can never fail. Result is set to "reject 1-65535", "accept 1-65535" or "%s %s" where the first is prefix and the latter the shorter policy entry.Tor: 0.2.9.x-finalhttps://gitlab.torproject.org/tpo/core/dirauth/-/issues/20065Being unable to load authority_signing_key should be an error2020-06-27T14:11:30ZSebastian HahnBeing unable to load authority_signing_key should be an errorCurrently, Tor fails with an obscure assertion a little while later if a dirauth op forgets to move the authority_signing_key file into place.Currently, Tor fails with an obscure assertion a little while later if a dirauth op forgets to move the authority_signing_key file into place.Tor: 0.2.9.x-finalhttps://gitlab.torproject.org/tpo/core/dirauth/-/issues/20064When allowing private addresses, assign Exit flag if 10.0.0.0/8 is exited to2020-06-27T14:11:30ZSebastian HahnWhen allowing private addresses, assign Exit flag if 10.0.0.0/8 is exited toIn a Tor network deployed in a custom network, none of the nodes get an Exit flag even tho they should qualify according to the spec. This is because internal addresses are skipped.In a Tor network deployed in a custom network, none of the nodes get an Exit flag even tho they should qualify according to the spec. This is because internal addresses are skipped.Tor: 0.2.9.x-finalhttps://gitlab.torproject.org/tpo/core/dirauth/-/issues/19785Agree and Prepare Formal Procedure to Add/Remove DirAuths2022-02-07T19:20:41ZcypherpunksAgree and Prepare Formal Procedure to Add/Remove DirAuthsWe need:
* a formal procedure for making the final decision (e.g. "Roger initiates a vote on <mailing list>; dirauths have 3 days to vote yes or no via PGP-signed email; a quorum of 7 votes is sufficient to make a decision; lack of quoru...We need:
* a formal procedure for making the final decision (e.g. "Roger initiates a vote on <mailing list>; dirauths have 3 days to vote yes or no via PGP-signed email; a quorum of 7 votes is sufficient to make a decision; lack of quorum => no change")
* a formal procedure for removing dirauths (rules will be different to accommodate excluding the instant dirauth from voting)
We also need a more inclusive and transparent discussion and voting process that in some way includes community input.
See also ticket legacy/trac#19271.https://gitlab.torproject.org/tpo/core/dirauth/-/issues/19271Remove urras from default_authorities2020-06-27T14:11:30ZcypherpunksRemove urras from default_authoritiesAs of this moment urras is still listed in default_authorities in
src/or/config.c.
This ticket is to consider removing it.
More broadly, does the Tor Project have a procedure for removing
dirauths, or for considering their removal?As of this moment urras is still listed in default_authorities in
src/or/config.c.
This ticket is to consider removing it.
More broadly, does the Tor Project have a procedure for removing
dirauths, or for considering their removal?Tor: 0.2.9.x-finalhttps://gitlab.torproject.org/tpo/core/dirauth/-/issues/18493What is 213.251.199.174?2020-06-27T14:11:30ZcypherpunksWhat is 213.251.199.174?Whois says it is related to ZAO Countrycom (countrycom.ru which is redirected to alloincognito.ru).
It is a cellular network operator holding brandname alloincognito.
You can get information about the organization from https://egrul.nal...Whois says it is related to ZAO Countrycom (countrycom.ru which is redirected to alloincognito.ru).
It is a cellular network operator holding brandname alloincognito.
You can get information about the organization from https://egrul.nalog.ru/download/CC43C3392FC5792F3E57E55B6E28EB9ED923F8CC17EE963DB67C641EB4B88E68522F932D2301BA4F349CE8DDEAD737AB7E271009A7A197157281A5B84E7D6A93
I see nothing special in it, it looks like a usual card of a little company.
I want to thank them for their contribution, but I think their contribution should be analyzed, because they have all licenses the telecom company in Russia must have to operate legally, to have the licenses they must send all the traffic from their networks to FSB.https://gitlab.torproject.org/tpo/core/dirauth/-/issues/18164Clean out old dirauth bad.conf entries2020-06-27T14:11:31Zmicahmicah@torproject.orgClean out old dirauth bad.conf entriesIn an effort to move towards standardizing bad.conf so it can be machine parseable (legacy/trac#17229 and legacy/trac#12261), because there is no process for cleaning out this file, and because there are entries in this file from 2007......In an effort to move towards standardizing bad.conf so it can be machine parseable (legacy/trac#17229 and legacy/trac#12261), because there is no process for cleaning out this file, and because there are entries in this file from 2007... we need to clean out the old entries in this file.
It was discussed in Berlin among some DA's about different approaches, at least three who used the repository indicated that they were fine with removing every entry in that file that was more than 6 months old.
We haven't done this yet. It is relatively easy to do, but before I just go in and delete most of that file and commit it, I wanted to give people the chance to comment on the proposed plan here.