The Tor Project issueshttps://gitlab.torproject.org/groups/tpo/-/issues2022-09-01T21:29:26Zhttps://gitlab.torproject.org/tpo/core/tor/-/issues/27047Authorities should keep recent consensuses, votes, and bandwidth files2022-09-01T21:29:26ZteorAuthorities should keep recent consensuses, votes, and bandwidth filesMoving https://trac.torproject.org/projects/tor/ticket/21378#comment:12 into a separate ticket:
Quoting teor:
> Replying to teor:
> > Replying to irl:
> > > Using the fixed URL http://<hostname>/tor/status-vote/next/bandwidth.z sounds ...Moving https://trac.torproject.org/projects/tor/ticket/21378#comment:12 into a separate ticket:
Quoting teor:
> Replying to teor:
> > Replying to irl:
> > > Using the fixed URL http://<hostname>/tor/status-vote/next/bandwidth.z sounds like it would be very easy to add this to CollecTor.
> >
> > Thanks for the feedback!
> >
> > > We have discussed in the Metrics team extending `dir-spec.txt` to allow to fetch "recent" files as well as just next/current. In the case that there is a wide CollecTor outage, and we miss a file, it would be good to have those files cached (on a best-effort basis, not necessarily persisted to disk) and available via some URL.
> >
> > How is this any different to losing descriptors or consensuses?
> > (Please answer this question on a separate ticket.)
> >
> > > I don't know if karsten already had some ideas about what these URLs would look like, but we should perhaps consider this before implementing changes to `dir-spec.txt`.
> >
> > Please open a separate ticket for this feature. It's potentially a large feature. And it's not essential for the initial release of this feature.
>
> If you open a separate ticket for historical directory documents, please make legacy/trac#26698 a child of that ticket. We'll need bandwidth file hashes to work out the exact file used in each vote.https://gitlab.torproject.org/tpo/core/tor/-/issues/27024Tor is now TSR and no way to terminate it2020-07-28T22:39:46ZTracTor is now TSR and no way to terminate itPlatform: Windows 7 home premium (64bit on amd64)
Tor version 7.5.6 (based on Mozilla 52.9.0 32-bit)
Tor used to work perfectly fine until an update maybe a month ago or so.
Now, when I close Tor, it never completely closes.
There ...Platform: Windows 7 home premium (64bit on amd64)
Tor version 7.5.6 (based on Mozilla 52.9.0 32-bit)
Tor used to work perfectly fine until an update maybe a month ago or so.
Now, when I close Tor, it never completely closes.
There seems to be no way to terminate the process tor.exe which I can still see in Windows7's Task Manager.
As a result, when I restart Tor, it refuses to launch. I get the message asking me whether I want to Exit or Relaunch. Except it goes into an endless loop, bringing me back to that choice, no matter how many times I select relaunch or exit - it makes no difference.
I've tried "end process", and "end process tree" from the Windows Task Manager. There is absolutely no way to terminate it.
The only solution is to reboot the system.
This was not necessary in the past.
Other software: Zone-Alarm, Ad-Aware
**Trac**:
**Username**: TimmiTor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/27021do not take self advertised bandwidth into account2020-06-27T13:52:40Ztoralfdo not take self advertised bandwidth into account1. It might result a long-term up and down of relay bw. Imageing a case, where for some reason a relay reports a lower traffic. It will get a lower weigth which yields into lower traffic and so on.
2. It invites people to manipulate th...1. It might result a long-term up and down of relay bw. Imageing a case, where for some reason a relay reports a lower traffic. It will get a lower weigth which yields into lower traffic and so on.
2. It invites people to manipulate the weight of their relays.
BTW: In IRC there are hints and tipps flying around how and where to change the Tor source code to manipulate the transferred traffic.https://gitlab.torproject.org/tpo/core/tor/-/issues/26999tor_api: Some way to capture stdout/stderr2020-07-28T22:39:25ZNick Mathewsontor_api: Some way to capture stdout/stderrIn legacy/trac#25510, hellais says:
> * Ability to get the output of tor_run_main() without having to mock standard out
> There is a wealth of information inside of the log output of tor, which would be nice if it were exposed in a ...In legacy/trac#25510, hellais says:
> * Ability to get the output of tor_run_main() without having to mock standard out
> There is a wealth of information inside of the log output of tor, which would be nice if it were exposed in a more API friendly way (maybe some sort of callback function?) so that a user of the library doesn't have to mock stdout/stderr.Tor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/26997tor_api: Do we want an easier way to set options?2020-07-28T22:39:06ZNick Mathewsontor_api: Do we want an easier way to set options?In the parent ticket legacy/trac#25510, hellais reports:
> * Add API calls for making it easier to setup the configuration for tor
> This is more of usability issue, but it would be great if the tor_api.h has some function for setting co...In the parent ticket legacy/trac#25510, hellais reports:
> * Add API calls for making it easier to setup the configuration for tor
> This is more of usability issue, but it would be great if the tor_api.h has some function for setting configuration options for Tor, without having to rely on passing them as command line arguments.Tor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/26993Tor silently ignores hidden directory when it isn't writable2022-09-01T21:29:26Zyurivict271Tor silently ignores hidden directory when it isn't writableI added HiddenServiceDir and HiddenServicePort to torrc.
When the empty HS directory has permissions 0600, tor starts without creating the HS and without complaining. It should either fail to start, or print a warning that the HS direct...I added HiddenServiceDir and HiddenServicePort to torrc.
When the empty HS directory has permissions 0600, tor starts without creating the HS and without complaining. It should either fail to start, or print a warning that the HS directory isn't writable.
When permissions is 300 though, tor complains that 'Directory x cannot be read'.
tor-0.3.3.7 on FreeBSD-12https://gitlab.torproject.org/tpo/core/tor/-/issues/26992Add intro point IPv6 address to service descriptors2021-09-30T13:45:56ZteorAdd intro point IPv6 address to service descriptorsImplemented as a consequence of legacy/trac#23576, but I need a ticket number.Implemented as a consequence of legacy/trac#23576, but I need a ticket number.Tor: unspecifiedteorteorhttps://gitlab.torproject.org/tpo/core/tor/-/issues/26987Tor seems to be reading from two different time sources in a macOS VM2020-06-27T13:52:42ZteorTor seems to be reading from two different time sources in a macOS VMI started chutney (and its tors) a few minutes after resuming from sleep, but Tor sometimes gets the time wrong by 15 hours. (Which is approximately the time the VM last slept.)
I wonder if we're using the wrong macOS time APIs?
Or it c...I started chutney (and its tors) a few minutes after resuming from sleep, but Tor sometimes gets the time wrong by 15 hours. (Which is approximately the time the VM last slept.)
I wonder if we're using the wrong macOS time APIs?
Or it could be a VM or macOS issue.
```
FAIL: ipv6-exit-min
Detail: chutney/tools/warnings.sh /Users/base/chutney/net/nodes.1532996702
Warning: Couldn't store my own vote! (I told myself, 'Bad valid-after time'.) Number: 2
Warning: Rejecting vote from 127.0.0.1 with valid-after time of 2018-07-31 00:26:05; we were expecting 2018-07-31 00:25:10 Number: 2
Warning: Your system clock just jumped 55189 seconds backward; assuming established circuits no longer work. Number: 3
Warning: Your system clock just jumped 55191 seconds forward; assuming established circuits no longer work. Number: 3
```Tor: 0.3.4.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/26979Appveyor CI IRC shows the wrong branch for pull requests2020-06-27T13:52:42ZteorAppveyor CI IRC shows the wrong branch for pull requestsFor example, the branch that Neel opened a pull request for is b23588, based on master:
```
11:49 appveyor-ci: torproject/tor master 1752b17 - Neel Chauhan: Add changes file for Bug #23588
11:49 appveyor-ci: Build #1.0.450 failed. Detail...For example, the branch that Neel opened a pull request for is b23588, based on master:
```
11:49 appveyor-ci: torproject/tor master 1752b17 - Neel Chauhan: Add changes file for Bug #23588
11:49 appveyor-ci: Build #1.0.450 failed. Details: https://ci.appveyor.com/project/torproject/tor/build/1.0.450
```
If I can't fix this in a few minutes tomorrow, I'll leave it for later.Tor: 0.3.4.x-finalteorteorhttps://gitlab.torproject.org/tpo/core/tor/-/issues/26973Privcount blinding and encryption: add rustfmt CI check2020-06-27T13:52:42ZteorPrivcount blinding and encryption: add rustfmt CI checkWe should check that rustfmt has been run on the privcount_shamir code in our CI. See:
https://trac.torproject.org/projects/tor/ticket/26955?replyto=3#comment:3We should check that rustfmt has been run on the privcount_shamir code in our CI. See:
https://trac.torproject.org/projects/tor/ticket/26955?replyto=3#comment:3Tor: 0.4.0.x-finalteorteorhttps://gitlab.torproject.org/tpo/core/tor/-/issues/26971Add rendezvous point unrecognised link specifiers to client introduce cells2022-06-16T18:01:57ZteorAdd rendezvous point unrecognised link specifiers to client introduce cellsLike legacy/trac#24181, we need to take unrecognised link specifiers from onion service descriptors, and put them in client introduce cells.
https://gitweb.torproject.org/torspec.git/tree/rend-spec-v3.txt#n1346Like legacy/trac#24181, we need to take unrecognised link specifiers from onion service descriptors, and put them in client introduce cells.
https://gitweb.torproject.org/torspec.git/tree/rend-spec-v3.txt#n1346https://gitlab.torproject.org/tpo/core/tor/-/issues/26970Privcount: plan the modules and components2020-07-28T22:37:36ZteorPrivcount: plan the modules and componentsReplying to [26953#comment:3 chelseakomlo]:
> Is the idea that this project will remain external to core tor, or will this one day be merged into the core codebase? Definitely having CI in the short term seems wise either way.
That's a ...Replying to [26953#comment:3 chelseakomlo]:
> Is the idea that this project will remain external to core tor, or will this one day be merged into the core codebase? Definitely having CI in the short term seems wise either way.
That's a good question, nickm and I haven't discussed it yet. And I think we'd benefit from your advice.
For PrivCount in Tor, we need to produce the following components:
* a Rust "Data Collector" module in Tor that does blinding, encryption, and noise, based on a config
* a separate "Tally Reporter" binary that does unblinding, decryption, aggregation, and reporting, based on a config
* some tools for creating and validating configurations
One possible design is:
* Rust modules for blinding/encryption, noise, aggregation, reporting, and config
* Glue code and module imports for the Tor Data Collector
* Application code and module imports for the Tally Reporter
* Application code and module imports for the tools
Split off https://trac.torproject.org/projects/tor/ticket/26953?replyto=3#comment:3Tor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/26958Privcount blinding and encryption: run clippy on travis rust nightly2020-07-28T22:37:33ZteorPrivcount blinding and encryption: run clippy on travis rust nightlyWe'll need to fix or disable a lot of warnings for clippy.We'll need to fix or disable a lot of warnings for clippy.Tor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/26957Privcount blinding and encryption: Derive copy and debug where possible2020-07-28T22:37:29ZteorPrivcount blinding and encryption: Derive copy and debug where possibleThe privcount shamir structs are missing copy and debug implementations.
komlo: are these useful?
If they are, we should derive them, and then enable the missing_copy_implementations and missing_debug_implementations warnings.The privcount shamir structs are missing copy and debug implementations.
komlo: are these useful?
If they are, we should derive them, and then enable the missing_copy_implementations and missing_debug_implementations warnings.Tor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/26954Appveyor: Add Rust builds on Windows2020-07-28T22:37:23ZteorAppveyor: Add Rust builds on WindowsThe Tor Browser team cross-compiles Tor with Rust for Windows.
It would be great if we had our own CI for Rust Windows builds.
There's a good thread with some scripts here:
https://users.rust-lang.org/t/rust-appveyor-windows-ci-scripts/...The Tor Browser team cross-compiles Tor with Rust for Windows.
It would be great if we had our own CI for Rust Windows builds.
There's a good thread with some scripts here:
https://users.rust-lang.org/t/rust-appveyor-windows-ci-scripts/4437Tor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/26945Privcount blinding and encryption: always enable i1282020-07-28T22:35:53ZteorPrivcount blinding and encryption: always enable i128See https://trac.torproject.org/projects/tor/ticket/25669#comment:12See https://trac.torproject.org/projects/tor/ticket/25669#comment:12Tor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/26944Privcount blinding and encryption: Add tests2020-07-28T22:35:57ZteorPrivcount blinding and encryption: Add testsAdd tests as recommended in https://trac.torproject.org/projects/tor/ticket/25669#comment:15Add tests as recommended in https://trac.torproject.org/projects/tor/ticket/25669#comment:15Tor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/26943Privcount blinding and encryption: Safety fixes2020-06-27T13:52:44ZteorPrivcount blinding and encryption: Safety fixesSafety fixes from https://trac.torproject.org/projects/tor/ticket/25669#comment:15Safety fixes from https://trac.torproject.org/projects/tor/ticket/25669#comment:15Tor: 0.4.0.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/26941Privcount blinding and encryption: review dependencies2020-07-28T22:36:00ZteorPrivcount blinding and encryption: review dependenciesExternal dependency review from https://trac.torproject.org/projects/tor/ticket/25669#comment:15External dependency review from https://trac.torproject.org/projects/tor/ticket/25669#comment:15Tor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/26940Privcount blinding and encryption: doc fixes2020-06-27T13:52:45ZteorPrivcount blinding and encryption: doc fixesDoc fixes from https://trac.torproject.org/projects/tor/ticket/25669#comment:15Doc fixes from https://trac.torproject.org/projects/tor/ticket/25669#comment:15Tor: 0.4.0.x-finalNick MathewsonNick Mathewson