The Tor Project issueshttps://gitlab.torproject.org/groups/tpo/-/issues2022-12-09T13:20:20Zhttps://gitlab.torproject.org/tpo/applications/tor-browser-spec/-/issues/32715Document our downloads.json file2022-12-09T13:20:20ZGeorg KoppenDocument our downloads.json fileWe have https://aus1.torproject.org/torbrowser/update_3/release/downloads.json (and a similar URL for alpha (s/release/alpha)) for users/devs that want to keep a reliable way for grabbing the latest updates or pull the latest version inf...We have https://aus1.torproject.org/torbrowser/update_3/release/downloads.json (and a similar URL for alpha (s/release/alpha)) for users/devs that want to keep a reliable way for grabbing the latest updates or pull the latest version information so that they can see when new updates are available.
The JSON file got specifically created to be easily parsable in legacy/trac#16651. This seems to work pretty well from all we know but we never documented that feature nor specified it.
We think this should finally be mentioned on our dev portal and we should write kind of a retroactive proposal and put it into our proposal folder in `tor-browser-spec` so that we have something official we can link to.https://gitlab.torproject.org/tpo/applications/tor-browser-spec/-/issues/25197Design document isn't precise about "Security" and "Privacy".2022-12-09T13:20:19ZArthur EdelsteinDesign document isn't precise about "Security" and "Privacy".In Tor Browser, we have a "Security" Slider and various "Privacy" features. But these words are not so easily distinguished. Maybe we could think of a better words?
In any case, we should defined the two concepts very clearly in the Des...In Tor Browser, we have a "Security" Slider and various "Privacy" features. But these words are not so easily distinguished. Maybe we could think of a better words?
In any case, we should defined the two concepts very clearly in the Design document, and we should make sure we don't mix them up. For example, section 2.1 is entitled "Security Requirements" but goes on to list what I would consider privacy properties and does not include the sort of security intended to be provided by the Slider.https://gitlab.torproject.org/tpo/applications/tor-browser-spec/-/issues/18820Integrate code signing into the release process2022-12-09T13:20:14ZGeorg KoppenIntegrate code signing into the release processWe should integrate the OS X code signing as good as we can into our release process. We have the following pieces at the moment
1) We create a .dmg file as the result of our build process
2) We have a signing machine where these files ...We should integrate the OS X code signing as good as we can into our release process. We have the following pieces at the moment
1) We create a .dmg file as the result of our build process
2) We have a signing machine where these files need to get transferred to
3) We need to sign the TorBrowser.app inside the .dmg file
4) We need to ship the .dmg file with the signed app
Taking these into account it seems quite cumbersome to automate this even a bit. But maybe there is something I am missing.
This ticket is not about signing/removing the signature in a reproducible fashion. Getting this going is very likely a separate fun task.https://gitlab.torproject.org/tpo/applications/tor-browser-spec/-/issues/31161Document usage and setup of Android signing token2023-07-13T08:20:04ZGeorg KoppenDocument usage and setup of Android signing tokenWe have documentation in `tor-browser-spec` about setting up our Windows signing token and should do the same for the Android one.
We could add the relevant instructions for using the whole setup on our actual signing machine in a separ...We have documentation in `tor-browser-spec` about setting up our Windows signing token and should do the same for the Android one.
We could add the relevant instructions for using the whole setup on our actual signing machine in a separate commit within this ticket's scope.Tor Browser: 11.0 Issues with previous releaseboklmboklmhttps://gitlab.torproject.org/tpo/applications/tor-browser-spec/-/issues/24945Tor Browser design doc says it whitelists flash and gnash as plugins2024-02-13T20:04:29ZRoger DingledineTor Browser design doc says it whitelists flash and gnash as pluginsThe Tor Browser design doc says "we also patch the Firefox source code to prevent the load of any plugins except for Flash and Gnash. Even for Flash and Gnash, we also patch Firefox to prevent loading them into the address space until th...The Tor Browser design doc says "we also patch the Firefox source code to prevent the load of any plugins except for Flash and Gnash. Even for Flash and Gnash, we also patch Firefox to prevent loading them into the address space until they are explicitly enabled."
If this is so, we should probably change Tor Browser to just prevent all plugins, including Flash and Gnash.
And if it is no longer so, we should fix the wrong statement in the design doc.
Noticed in legacy/trac#10885.https://gitlab.torproject.org/tpo/applications/tor-browser-spec/-/issues/33070Update website traffic fingerprinting section in tor browser design doc2023-11-08T20:48:06ZGeorg KoppenUpdate website traffic fingerprinting section in tor browser design docThe website traffic fingerprinting section needs to get updated as there have been a bunch of more or less recent developments that are not accounted for in it. In particular our [recent blog post](https://blog.torproject.org/new-low-cos...The website traffic fingerprinting section needs to get updated as there have been a bunch of more or less recent developments that are not accounted for in it. In particular our [recent blog post](https://blog.torproject.org/new-low-cost-traffic-analysis-attacks-mitigations) about low cost attacks in this space could be a good starting point for getting the update going.https://gitlab.torproject.org/tpo/applications/tor-browser-spec/-/issues/25021Update Tor Browser spec2024-03-20T23:28:07ZGeorg KoppenUpdate Tor Browser specTor Browser 11.0 is coming out soon. We should update our design document to cover all the new issues that are showing up in it. Highlights are
1) Switch to rbm/tor-browser-build
2) The security slider copy update
...
The update should...Tor Browser 11.0 is coming out soon. We should update our design document to cover all the new issues that are showing up in it. Highlights are
1) Switch to rbm/tor-browser-build
2) The security slider copy update
...
The update should cover the current goals and state of the browser, and fold in all the 8.0, 8.5, 9.0, 9.5, 10.0, and 10.5 changes.Tor Browser: 11.0 Issues with previous releaserichardrichardhttps://gitlab.torproject.org/tpo/core/tor/-/issues/25061Relays log a bootstrap warning if they can't extend for somebody else's circuit2020-10-20T10:28:37ZRoger DingledineRelays log a bootstrap warning if they can't extend for somebody else's circuitSay you have a relay that is up and listed as non-slow in the consensus. Due to the current overload (legacy/trac#24902), this relay is getting many many circuit requests per second. Due to bug legacy/trac#24767, we will make a huge numb...Say you have a relay that is up and listed as non-slow in the consensus. Due to the current overload (legacy/trac#24902), this relay is getting many many circuit requests per second. Due to bug legacy/trac#24767, we will make a huge number of connection attempts to other relays that are down, because as soon as we get a "connection refused", we will get another circuit request that triggers another connection attempt.
So when your relay restarts, since it's still in the consensus and clients still think it's usable, it will immediately get flooded with circuit requests, causing these connection attempts to resume.
And Tor calls every one of those connection attempts a bootstrapping attempt, even if there are no origin circuits related to that connection attempt.Tor: 0.4.5.x-freezeNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/40127Link Tor's code into one big .a file.2020-10-23T14:36:38ZNick MathewsonLink Tor's code into one big .a file.Managing all our little libraries has proved too much for too many downstream apps. Let's make one big static library.Managing all our little libraries has proved too much for too many downstream apps. Let's make one big static library.Tor: 0.4.5.x-stableNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/7193Tor's sybil protection doesn't consider IPv62021-08-23T15:19:19ZGeorge KadianakisTor's sybil protection doesn't consider IPv6Some bugs:
`get_possible_sybil_list()` doesn't consider IPv6 addresses at all.
~~`clear_status_flags_on_sybil()` doesn't clear `ipv6_addr` (and maybe more flags).~~ Obsoleted by consensus method 24, because it requires the Running flag...Some bugs:
`get_possible_sybil_list()` doesn't consider IPv6 addresses at all.
~~`clear_status_flags_on_sybil()` doesn't clear `ipv6_addr` (and maybe more flags).~~ Obsoleted by consensus method 24, because it requires the Running flag for a router to be in the consensus.
Also, maybe we could add a `log_notice` or `log_info` to mention if and which relays were found to be part of a Sybil attack.
~~Finally (and this is a minor bug), in `get_possible_sybil_list()` we assume that `max_with_same_addr < max_with_same_addr_on_authority`, which is true in the current tor network, but maybe it shouldn't be an inherent property of the source code.~~ Obsoleted by legacy/trac#20960: max_with_same_addr_on_authority has been removed.Tor: 0.4.5.x-freezeNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/40138Give configure-time warnings on API mismatch with Openssl headers and libraries2020-10-07T13:00:58ZNick MathewsonGive configure-time warnings on API mismatch with Openssl headers and librariesIn #33437, @jsw ran into a usability problem that happens when our configure script finds the openssl headers in one place but finds the libraries in another. Instead of complaining, the script succeeds, but later on compilation fails.
...In #33437, @jsw ran into a usability problem that happens when our configure script finds the openssl headers in one place but finds the libraries in another. Instead of complaining, the script succeeds, but later on compilation fails.
I'd like to improve our openssl detection, but it's a longstanding problem to do that without breaking backward compatibility with existing configure users.
So as a usability measure, let's give a better warning when we find ourselves in this situation, and let's make it hard to overlook.Tor: 0.4.5.x-freezeNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/40162Un-require Desc=1, Cons=1, Microdesc=1.2021-01-11T18:57:18ZNick MathewsonUn-require Desc=1, Cons=1, Microdesc=1.The abovementioned subprotocol versions are the older versions of the documents that were generated before Ed25519 keys were included. Authorities should not require them any more.
This is related to proposal 315 and #40132. It ought t...The abovementioned subprotocol versions are the older versions of the documents that were generated before Ed25519 keys were included. Authorities should not require them any more.
This is related to proposal 315 and #40132. It ought to go in soon.Tor: 0.4.4.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/40129--disable-module-relay gives warnings with ALL_BUGS_ARE_FATAL2020-10-07T10:43:24ZNick Mathewson--disable-module-relay gives warnings with ALL_BUGS_ARE_FATALSome example warnings:
```
src/feature/dircache/dircache_stub.c: In function ‘directory_handle_command’:
src/feature/dircache/dircache_stub.c:18:1: error: function might be candidate for attribute ‘noreturn’ [-Werror=suggest-attribute=no...Some example warnings:
```
src/feature/dircache/dircache_stub.c: In function ‘directory_handle_command’:
src/feature/dircache/dircache_stub.c:18:1: error: function might be candidate for attribute ‘noreturn’ [-Werror=suggest-attribute=noreturn]
18 | directory_handle_command(dir_connection_t *conn)
| ^~~~~~~~~~~~~~~~~~~~~~~~
src/feature/dircache/dircache_stub.c: In function ‘connection_dirserv_flushed_some’:
src/feature/dircache/dircache_stub.c:26:1: error: function might be candidate for attribute ‘noreturn’ [-Werror=suggest-attribute=noreturn]
26 | connection_dirserv_flushed_some(dir_connection_t *conn)
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
CC src/lib/ctime/libtor_ctime_a-di_ops.o
cc1: all warnings being treated as errors
```Tor: 0.4.4.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/32181remove custom Android logging, use syslog2021-09-16T14:22:37Zeighthaveremove custom Android logging, use syslogAs far as I can tell, syslog.h is fully supported for logging to Android's logcat. `syslog.h` is present as early as NDK r10e, if not earlier. It is also included on _android-9_ (2.3). My quick tests show syslog working fine on _andro...As far as I can tell, syslog.h is fully supported for logging to Android's logcat. `syslog.h` is present as early as NDK r10e, if not earlier. It is also included on _android-9_ (2.3). My quick tests show syslog working fine on _android-22_ (5.1) through _android-29_ (10) emulators. _android-24_ (7.0) is currently the oldest version of Android supported by Google. syslog severity and identity tag are already mapped to the logcat versions.
@ahf is there some detail I'm missing? Were you having problems with syslog on Android?
Since the "android" logging option was never documented, I think it should just be removed, long with the `add_android_log()` code that was added in legacy/trac#24362 https://github.com/torproject/tor/commit/b0b8f7c30c8296344c77d06a24821f35b667e3dd
FYI, since syslog support is added about the same time as logcat support, legacy/trac#32036 is still an issue when using syslog with Android.Nick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/40137Purge long-obsolete fields from State file2021-08-23T15:12:44ZNick MathewsonPurge long-obsolete fields from State fileThere are some fields in the state file that are so obsolete, we no longer update them to newer versions with current version of Tor. If you find that you have one of these in your state file, Tor will keep it around for you forever, si...There are some fields in the state file that are so obsolete, we no longer update them to newer versions with current version of Tor. If you find that you have one of these in your state file, Tor will keep it around for you forever, since the state file format is intended to preserve unrecognized fields.
We should make our code delete state fields that are known to have been obsolete for a very long time, to avoid possible information leakage.Nick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/torspec/-/issues/31Audit list of network parameters for completeness2021-09-16T14:40:39ZNick MathewsonAudit list of network parameters for completeness`dir-spec` has a big list of network parameters, but is it complete? No, it's missing at least ExtendByEd25519. What else might it be missing? We should find out.`dir-spec` has a big list of network parameters, but is it complete? No, it's missing at least ExtendByEd25519. What else might it be missing? We should find out.Nick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/40139Identify network parameters that we can deprecate and remove.2021-09-16T14:21:52ZNick MathewsonIdentify network parameters that we can deprecate and remove.We've accumulated a lot of network parameters. Some of them are explicitly intended to be transitional; some of them are probably obsolete. We should come up with a plan to trim the list down.We've accumulated a lot of network parameters. Some of them are explicitly intended to be transitional; some of them are probably obsolete. We should come up with a plan to trim the list down.Nick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/torspec/-/issues/25Update dir-spec with client fallback directory mirror attempt and timeout beh...2020-10-19T12:45:06ZteorUpdate dir-spec with client fallback directory mirror attempt and timeout behaviourLet's add these lines:
Clients try several fallback directory mirrors, and use the first one that connects. Each attempt happens after a short delay, regardless of the state of the previous attempt, until at least one attempt has connec...Let's add these lines:
Clients try several fallback directory mirrors, and use the first one that connects. Each attempt happens after a short delay, regardless of the state of the previous attempt, until at least one attempt has connected.
When several fallback directory mirrors have failed, clients start trying directory authorities in a similar fashion.
Somewhere near:
https://gitweb.torproject.org/torspec.git/tree/dir-spec.txt#n3292
I don't think we designed any explicit timeout behaviour, so we are probably using whatever was there before 0.2.8.Nick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/40149Remove AUTHORS sections from manual pages2020-10-13T13:47:33ZNick MathewsonRemove AUTHORS sections from manual pagesInspired by #40148 from @arma .
The authors section is discouraged by [man-pages(7)](https://man7.org/linux/man-pages/man7/man-pages.7.html); our authors section is very much out of date, since it only lists me and Roger, and uses non-t...Inspired by #40148 from @arma .
The authors section is discouraged by [man-pages(7)](https://man7.org/linux/man-pages/man7/man-pages.7.html); our authors section is very much out of date, since it only lists me and Roger, and uses non-tor affiliated email for us.
I suggest that we remove the AUTHORS section from the manpages distributed with tor.
@tpo/core any objections?Nick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/40136Revise doc/state-contents.txt to be accurate2021-09-16T14:21:52ZNick MathewsonRevise doc/state-contents.txt to be accurateThe doc/state-contents.txt file is out of date, and missing a bunch of documentation.
We should have accurate documentation for all of the state file's contents.
The following elements are undocumented:
* BWHistoryIPv6ReadEnds
* BWHi...The doc/state-contents.txt file is out of date, and missing a bunch of documentation.
We should have accurate documentation for all of the state file's contents.
The following elements are undocumented:
* BWHistoryIPv6ReadEnds
* BWHistoryIPv6ReadInterval
* BWHistoryIPv6ReadValues
* BWHistoryIPv6ReadMaxima
* BWHistoryIPv6WriteEnds
* BWHistoryIPv6WriteInterval
* BWHistoryIPv6WriteValues
* BWHistoryIPv6WriteMaxima
* Guard
* TotalBuildTimes
* CircuitBuildAbandonedCount
* "CircuitBuildTimeBin"
* "BuildtimeHistogram"
* "MinutesSinceUserActivity"
* "Dormant"
The follow elements are obsolete:
* "EntryGuard"
* "EntryGuardDownSince"
* "EntryGuardUnlistedSince"
* "EntryGuardAddedBy"
These are obsolete _and_ undocumented:
* "EntryGuardPathBias"
* "EntryGuardPathUseBias"
* HidServRevCounterTor: 0.4.5.x-freezeNick MathewsonNick Mathewson