Trac issueshttps://gitlab.torproject.org/legacy/trac/-/issues2020-06-13T18:01:02Zhttps://gitlab.torproject.org/legacy/trac/-/issues/18035Review proposed fallback directory script fixes2020-06-13T18:01:02ZteorReview proposed fallback directory script fixesReview the fixes in
https://lists.torproject.org/pipermail/tor-relays/2016-January/008504.htmlReview the fixes in
https://lists.torproject.org/pipermail/tor-relays/2016-January/008504.htmlTor: 0.2.8.x-finalteorteorhttps://gitlab.torproject.org/legacy/trac/-/issues/18242Revert no-assertions-on-coverage, or make it controlled by an option.2020-06-13T14:54:02ZNick MathewsonRevert no-assertions-on-coverage, or make it controlled by an option.In 1228dd293b60a we made TOR_COVERAGE equavalent to NDEBUG so that branch coverage could be accurate.
But we hate NDEBUG.
I just spent 20 minutes too long debugging a problem because I'd forgotten that I was building with enable_cover...In 1228dd293b60a we made TOR_COVERAGE equavalent to NDEBUG so that branch coverage could be accurate.
But we hate NDEBUG.
I just spent 20 minutes too long debugging a problem because I'd forgotten that I was building with enable_coverage and that as such I shouldn't expect tor_assert to do anything.
We should either revert 1228dd293b60a, or make an --enable-branch-coverage option for configure that you have to use if you want to do branch coverage this way.Tor: 0.2.8.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/18139Update dir-spec for fallback directory mirrors2020-06-13T14:53:42ZteorUpdate dir-spec for fallback directory mirrorsIn #18086, we added default fallback directory mirrors to tor's master branch (0.2.8.0-alpha-dev).
I need to update the directory spec for that change.In #18086, we added default fallback directory mirrors to tor's master branch (0.2.8.0-alpha-dev).
I need to update the directory spec for that change.Tor: 0.2.8.x-finalteorteorhttps://gitlab.torproject.org/legacy/trac/-/issues/17573Update max_dl_per_request for IPv6 address length2020-06-13T14:53:25ZteorUpdate max_dl_per_request for IPv6 address lengthmax_dl_per_request depends on the maximum length of a textual IPv4 address.
To query IPv6 directories, the NS and MICRODESC calculations need to be updated for the maximum length of a textual IPv6 address in a URL. (That is, no brackets...max_dl_per_request depends on the maximum length of a textual IPv4 address.
To query IPv6 directories, the NS and MICRODESC calculations need to be updated for the maximum length of a textual IPv6 address in a URL. (That is, no brackets.)
While we're doing that, it would be nice to add a comment with the microdescriptor length calculation as well.Tor: 0.2.8.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/17906Dannenberg's v3ident needs to change2020-06-13T14:52:51ZDamian JohnsonDannenberg's v3ident needs to changeHi Nick. On [#17668](https://trac.torproject.org/projects/tor/ticket/17668#comment:19) I mentioned that Dannenberg's v3ident has changed and this needs to be [updated in config.c](https://gitweb.torproject.org/tor.git/tree/src/or/config....Hi Nick. On [#17668](https://trac.torproject.org/projects/tor/ticket/17668#comment:19) I mentioned that Dannenberg's v3ident has changed and this needs to be [updated in config.c](https://gitweb.torproject.org/tor.git/tree/src/or/config.c#n899). Trivial change, but this should be corrected soonish since due to it Dannenberg isn't taking part in the consensus...
```
from stem.descriptor import DocumentHandler
from stem.descriptor.remote import DescriptorDownloader
downloader = DescriptorDownloader()
print("Consensus is signed by...\n")
query = downloader.get_consensus(document_handler = DocumentHandler.BARE_DOCUMENT)
for authority in query.run()[0].directory_authorities:
print(' * %s with the v3ident of %s' % (authority.nickname, authority.v3ident))
```
```
% python scrap.py
Consensus is signed by...
* tor26 with the v3ident of 14C131DFC5C6F93646BE72FA1401C02A8DF2E8B4
* longclaw with the v3ident of 23D15D965BC35114467363C165C4F724B64B4F66
* maatuska with the v3ident of 49015F787433103580E3B66A1707A00E60F2D15B
* urras with the v3ident of 80550987E1D626E3EBA5E5E75A458DE0626D088C
* moria1 with the v3ident of D586D18309DED4CD6D57C18FDB97EFA96D330566
* dizum with the v3ident of E8A9C45EDE6D711294FADF8E7951F4DE6CA56B58
* gabelmoo with the v3ident of ED03BB616EB2F60BEC80151114BB25CEF515B226
* Faravahar with the v3ident of EFCBE720AB3A82B99F9E953CD5BF50F7EEFC7B97
```
Again, trivial change. Andreas sent a signed email to dir-auth@ on November 18...
```
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Hello.
The new v3ident for dannenberg is
'0232AF901C31A04EE9848595AF9BB7620D4C5B2E'.
Best
Andreas
-----BEGIN PGP SIGNATURE-----
Comment: Someone you trust is one of us.
iQIcBAEBCAAGBQJWTL7WAAoJECXskyqUhQcxB6IP/3K61NqgLbczZPydJfdxiTFK
OYbQn4j6Q4i3eIHBEyvqSgwEwMmlOe5cxJy/ean+mOyNmgqRUqJxIRQa/7ASmtqA
o/exZI/MKfCltZoSRCk1t1fBYUAlyToI7DLiA0hGBmeVkat9wlkRQUQD3N8XklAh
vJeix9CeIgbkpXxo6p7zmue9NZ2VtkCMJvHn0OmXzrzZIvE6X+uXyEhr/VDOzCnF
hVenqfGzSOP66xiG+b5aXavPjMj/1siw5cItq0CBsz33hL0O1/a/IlrUDhIjcspK
AfBBxmf4rZD0249UpvGoANebRaa+0PVfTqQXzntP4NqXSG6z0O/0bMLvj2Hf1xct
CKhhvSaIUFFru902U81ADnXSgbEDmeDVA9pfi17fJbLoRxAdOElDY3nw8YHGw3+n
FrmUKlZdw9hdEb9N6RXHfTN+NySjxXIz96Pirjt5WuaQ8GWeEislaWgLDuu+7nki
kg6zkmk3qA+i2818aasdN1HSSkuNIYp8NRGf8o6y1HiUdcFnMK2ZybPJfrOT2mUO
znLOPtarnqfdk7itOjMZnyR75URGDRFA0vNt7AWAuMhxrW8K1qz3q+wUS7lmBRCc
GeKE/OS4NSehTp2CWm48mm8BlO2ydHLg0G84oSTQpZAbPsfOBhg+aDKzJsi44lU8
YRb8Ii9mpPrCAu3QTSIX
=j8XS
-----END PGP SIGNATURE-----
```Tor: 0.2.8.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/17888Fallback directories: consider disabling exit consensus weight reduction2020-06-13T14:52:45ZteorFallback directories: consider disabling exit consensus weight reductionSome exit operators[0] report their exits have light loads.
Perhaps we should disable, or reduce the severity of (50%?) the exit consensus weight reduction, particularly during the opt-in period.
[0]: https://lists.torproject.org/piper...Some exit operators[0] report their exits have light loads.
Perhaps we should disable, or reduce the severity of (50%?) the exit consensus weight reduction, particularly during the opt-in period.
[0]: https://lists.torproject.org/pipermail/tor-relays/2015-December/008365.htmlTor: 0.2.8.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/17887Let fallback script use day-old data2020-06-13T14:52:44ZteorLet fallback script use day-old dataIn #16907, Onionoo will be updated to return a 504 error when data is more than 6 hours old. karsten also notes that Onionoo was down for 10 hours doing backups.
If we're updating fallback directories for a release, we don't want to wai...In #16907, Onionoo will be updated to return a 504 error when data is more than 6 hours old. karsten also notes that Onionoo was down for 10 hours doing backups.
If we're updating fallback directories for a release, we don't want to wait for Onionoo. So if there's cached data younger than a day, or if the data is stale and younger than a day, we'll use it.
I'll post a patch to this once I have the number.Tor: 0.2.8.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/17583manual missing --keygen description2020-06-13T14:50:54Zcypherpunksmanual missing --keygen descriptionhttps://www.torproject.org/docs/tor-manual-dev.html.en
```
OfflineMasterKey 0|1
If non-zero, the Tor relay will never generate or load its master secret key. Instead, you’ll have to use "tor --keygen" to manage the master secret key...https://www.torproject.org/docs/tor-manual-dev.html.en
```
OfflineMasterKey 0|1
If non-zero, the Tor relay will never generate or load its master secret key. Instead, you’ll have to use "tor --keygen" to manage the master secret key. (Default: 0)
```
but the manual does not contain a description of the --keygen parameter.Tor: 0.2.7.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/17270Evaluate non-C tor implementations for hackability2020-06-13T14:50:07ZNick MathewsonEvaluate non-C tor implementations for hackabilityFor testing, we should have badly-behaved clients and servers. But implementing that in C seems like horrible overkill. Let's look at the best-of-breed compatible implementations, and figure out which one would be the best basis for ma...For testing, we should have badly-behaved clients and servers. But implementing that in C seems like horrible overkill. Let's look at the best-of-breed compatible implementations, and figure out which one would be the best basis for making a bunch of stub test client/servers.
(It's okay if the client answer and the server answer aren't the same)Tor: 0.2.8.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/17269Draft process to ensure tickets and proposals get reviewed2020-06-13T14:50:06ZNick MathewsonDraft process to ensure tickets and proposals get reviewedOur current process doesn't do much to provide a deadline by which people can expect that their patches will be reviewed. It also doesn't push proposals towards an up/down resolution.
We need to make changes in this area, since having ...Our current process doesn't do much to provide a deadline by which people can expect that their patches will be reviewed. It also doesn't push proposals towards an up/down resolution.
We need to make changes in this area, since having a bunch of "needs_review" items sticking around is bad for getting volunteers online and making Tor better.
Target: Nov 2015.Tor: 0.2.8.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/17260Triage all items for 0.2.82020-06-13T14:50:02ZNick MathewsonTriage all items for 0.2.8Target date: 15 October 2015.
Remaining steps are:
* Make sure that every item on the roadmaps has a corresponding ticket.
* Prioritize items, under the assumption we can't possibly do them all so we'll probably need to aim for the ...Target date: 15 October 2015.
Remaining steps are:
* Make sure that every item on the roadmaps has a corresponding ticket.
* Prioritize items, under the assumption we can't possibly do them all so we'll probably need to aim for the really critical ones first.Tor: 0.2.8.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/15233Form a plan for killing off 0.2.2 and 0.2.32020-06-13T14:45:50ZNick MathewsonForm a plan for killing off 0.2.2 and 0.2.3#9476 is looking tricky; we should make a plan for what to do if it turns out maxmially tricky, and a plan for what to do when we're finally done with 0.2.3 as well.#9476 is looking tricky; we should make a plan for what to do if it turns out maxmially tricky, and a plan for what to do when we're finally done with 0.2.3 as well.Tor: 0.2.8.x-finalNick MathewsonNick Mathewson