Trac issueshttps://gitlab.torproject.org/legacy/trac/-/issues2020-06-13T13:30:41Zhttps://gitlab.torproject.org/legacy/trac/-/issues/28351Test clock skewed clients using chutney2020-06-13T13:30:41ZteorTest clock skewed clients using chutneyTo test #23605, we could run chutney with the clients clock skewed using chutney.
Alternately, we could launch the clients from a chutney network on a separate, skewed machine; or launch the clients and onion services on the public netw...To test #23605, we could run chutney with the clients clock skewed using chutney.
Alternately, we could launch the clients from a chutney network on a separate, skewed machine; or launch the clients and onion services on the public network (but we'd need exits?).https://gitlab.torproject.org/legacy/trac/-/issues/21039Refactor and simplify guard code of circuit_send_next_onion_skin()2020-06-13T15:04:47ZGeorge KadianakisRefactor and simplify guard code of circuit_send_next_onion_skin()As part of prop271 (#19877), we added about 70 fresh lines of code to `circuit_send_next_onion_skin()` which is an already convoluted function.
Ideally we should abstract this new circuit-related guard code and put it in its own functio...As part of prop271 (#19877), we added about 70 fresh lines of code to `circuit_send_next_onion_skin()` which is an already convoluted function.
Ideally we should abstract this new circuit-related guard code and put it in its own functions, to reduce complexity of `circuit_send_next_onion_skin()` and maybe even make it unittestable.Tor: unspecifiedGeorge KadianakisGeorge Kadianakishttps://gitlab.torproject.org/legacy/trac/-/issues/23573Do we want to close all connections when tor closes?2020-06-13T15:14:08ZteorDo we want to close all connections when tor closes?I have a branch for privcount that closes all connections before tor shuts down. Is this a feature that we want?I have a branch for privcount that closes all connections before tor shuts down. Is this a feature that we want?Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/23846Option to build Tor with -fPIC (Use libtool for building shared library?)2020-06-13T15:15:47ZArturo FilastòOption to build Tor with -fPIC (Use libtool for building shared library?)It seems like it's ideal to use libtool for generating a shared library. Simone made some progress on getting this working here: https://github.com/bassosimone/mkok-onion-event/pull/2/files.It seems like it's ideal to use libtool for generating a shared library. Simone made some progress on getting this working here: https://github.com/bassosimone/mkok-onion-event/pull/2/files.Tor: 0.3.5.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/23061crypto_rand_double() should produce all possible outputs on platforms with 32...2020-06-13T15:16:34Zteorcrypto_rand_double() should produce all possible outputs on platforms with 32-bit intOn 32-bit platforms, crypto_rand_double() only produces 1 in every 2 million possible values between 0 and 1.
This happens because:
* crypto_rand_double() divides a random unsigned int by UINT_MAX
* an unsigned int on 32-bit platforms i...On 32-bit platforms, crypto_rand_double() only produces 1 in every 2 million possible values between 0 and 1.
This happens because:
* crypto_rand_double() divides a random unsigned int by UINT_MAX
* an unsigned int on 32-bit platforms is 32 bits
* the mantissa on a double is 53 bits
So crypto_rand_double() doesn't fill the lower 21 bits with random values.
This makes the rep_hist_format_hs_stats() noise more predictable on 32-bit platforms.
This fix shouldn't affect the unit tests, because they pass on 64-bit.Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/24064Memory profiling of Tor on Android device2020-06-13T15:16:38ZAlexander Færøyahf@torproject.orgMemory profiling of Tor on Android deviceWe should collect measurements of memory usage on Android devices in a reproducible manner.We should collect measurements of memory usage on Android devices in a reproducible manner.Tor: 0.4.0.x-finalAlexander Færøyahf@torproject.orgAlexander Færøyahf@torproject.orghttps://gitlab.torproject.org/legacy/trac/-/issues/24204Improve the in-process Tor API: create owning control port2020-06-13T15:17:11ZNick MathewsonImprove the in-process Tor API: create owning control portIt would be good to have an interface something like this for controller authors to use, if they're embedding Tor:
```
#ifdef _WIN32
#define CONTROL_SOCKET SOCKET
#else
#define CONTROL_SOCKET int
#endif
/**
* Tells Tor to create a sock...It would be good to have an interface something like this for controller authors to use, if they're embedding Tor:
```
#ifdef _WIN32
#define CONTROL_SOCKET SOCKET
#else
#define CONTROL_SOCKET int
#endif
/**
* Tells Tor to create a socket for an owning controller connection to the
* Tor that will be launched. Return the socket.
*/
CONTROL_SOCKET tor_main_configuration_setup_control_socket(
tor_main_configuration_t *cfg);
#idef _WIN32
/** Windows-only; experimental. Tells Tor to create an anonymous pipe
* (whatever that's called) as an owning connection for the he controller, and
* and return that pipe. */
HANDLE tor_main_configuration_setup_control_pipe(
tor_main_configuration_t *cfg);
#endif
```
We should make sure it's portable, and that it can be implemented both with libtor_runner and with in-process Tor.Tor: 0.3.5.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/24586Audit all state for stuff we need to reset on exit to make tor restartable.2020-06-13T15:18:43ZNick MathewsonAudit all state for stuff we need to reset on exit to make tor restartable.We should, as a last step in making tor restartable, go through all of our state to see whether there are any flags we need to clear or things we need to free.We should, as a last step in making tor restartable, go through all of our state to see whether there are any flags we need to clear or things we need to free.Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/24803Generate a new fallback list in 2018 and backport it to all supported versions2020-06-13T15:19:50ZteorGenerate a new fallback list in 2018 and backport it to all supported versionsThis is the actual list generation ticket.This is the actual list generation ticket.Tor: 0.2.9.x-finalColin ChildsColin Childshttps://gitlab.torproject.org/legacy/trac/-/issues/24838Fuzzy match the fallback whitelist2020-06-13T15:20:06ZteorFuzzy match the fallback whitelistWe can rely on Onionoo to tell us when relay fingerprints or addresses change, so we don't need to do an exact match.
But listing fingerprints, addresses and ports in the whitelist is useful so that we know what a relay operator origina...We can rely on Onionoo to tell us when relay fingerprints or addresses change, so we don't need to do an exact match.
But listing fingerprints, addresses and ports in the whitelist is useful so that we know what a relay operator originally asked for.
Fuzzy matching simplifies maintaining the fallback whitelist, because we don't have to ask operators to update their relay details. (Or ask if those details are permanent.)
We deleted the blacklist in #26502.Tor: 0.4.0.x-finalteorteorhttps://gitlab.torproject.org/legacy/trac/-/issues/25263Fix the hidden service statistics noise (and the privcount noise by extension)2020-06-13T15:22:04ZteorFix the hidden service statistics noise (and the privcount noise by extension)Top-level task for hidden service statistics noise bugsTop-level task for hidden service statistics noise bugsTor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/25493Improve patterns for cleaning up static variables on exit/restart2020-06-13T15:22:57ZNick MathewsonImprove patterns for cleaning up static variables on exit/restartIn his review for #23524, asn says:
>I feel like resetting all the global statics on `tor_free_all()` makes sense but it's all a very brittle logic. The moment someone adds a new global static in that file and doesn't know about this con...In his review for #23524, asn says:
>I feel like resetting all the global statics on `tor_free_all()` makes sense but it's all a very brittle logic. The moment someone adds a new global static in that file and doesn't know about this convention of wiping at `tor_free_all()`, it will introduce a bug IIUC. Furthermore, the fact that some of those vars get reset to 0 and others to 1 is kinda arbitrary (and you need to look at their definitions to see if it's correct).
>
>I wonder what we could do about `3809036` to make it better. Perhaps we should de-global those variables, put them in a struct, and initialize them in a function, then call that function from some entry-point and `tor_free_all()`? That seems like a better approach but probably not so trivial. Maybe subject for a future ticket on this area?
We should indeed look for better patterns to solve this issue, since the current approach is indeed fragile.Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/25607On restart-in-process, do the right thing with thread-local storage2020-06-13T15:23:33ZNick MathewsonOn restart-in-process, do the right thing with thread-local storageWe use thread-local storage in one or two places; we should make sure that when tor shuts down, it's dropped, and when tor starts up again in the same process, it's created as an independent key.We use thread-local storage in one or two places; we should make sure that when tor shuts down, it's dropped, and when tor starts up again in the same process, it's created as an independent key.Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/25647Encoding/decoding logic for wide create(d) and extend(ed) cells2020-06-13T15:23:44ZNick MathewsonEncoding/decoding logic for wide create(d) and extend(ed) cellsTo implement prop249, we'll need a way to encode and decode wide create and extend cells.To implement prop249, we'll need a way to encode and decode wide create and extend cells.Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/25648Send create2v cells as needed; send created2v cells as needed (Prop249)2020-06-13T15:23:44ZNick MathewsonSend create2v cells as needed; send created2v cells as needed (Prop249)For wide creates, we need to send wide create2v and created2v cells when appropriate.
This will require checking for the advertisement of a particular protocol versionFor wide creates, we need to send wide create2v and created2v cells when appropriate.
This will require checking for the advertisement of a particular protocol versionTor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/25649Send a series of extend2/extended2 cells as needed to encode a wide create/cr...2020-06-13T15:23:45ZNick MathewsonSend a series of extend2/extended2 cells as needed to encode a wide create/created pair (prop249)As part of prop249, we need to be able to send wide onion handshakes split across multiple relay cells.As part of prop249, we need to be able to send wide onion handshakes split across multiple relay cells.Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/25650Handle incoming create2v / created2v cells (wide create cells)2020-06-13T15:23:45ZNick MathewsonHandle incoming create2v / created2v cells (wide create cells)We need to receive create2v/created2v cells, and respond to them by performing or finishing the corresponding onion handshake.We need to receive create2v/created2v cells, and respond to them by performing or finishing the corresponding onion handshake.Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/25651Handle incoming extend2/extended2 fragmented requests/replies. (prop249)2020-06-13T15:23:46ZNick MathewsonHandle incoming extend2/extended2 fragmented requests/replies. (prop249)As part of prop249, we need to handle large create cells when they arrive fragmented across multiple extend cells (and similarly for created cells fragmented across multiple extended cells).
Important notes:
* The proposal says that t...As part of prop249, we need to handle large create cells when they arrive fragmented across multiple extend cells (and similarly for created cells fragmented across multiple extended cells).
Important notes:
* The proposal says that there must be no intervening cells on the same circuit. We should enforce this and test it.
* We should probably use a buf_t object to record these handshakes as they are being assembled.
* We should count these handshakes against the memory usage of a circuit and age of the oldest queued data, so that they will participate correctly in the OOM system.Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/25652Prop249: set RELAY_EARLY bit correctly on fragmented EXTEND cells; enforce it...2020-06-13T15:23:46ZNick MathewsonProp249: set RELAY_EARLY bit correctly on fragmented EXTEND cells; enforce it correctly.The RELAY_EARLY bit gets a tiny bit more complicated with prop249; let's make sure we implement it correctly.The RELAY_EARLY bit gets a tiny bit more complicated with prop249; let's make sure we implement it correctly.Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/25653prop249: advertise support correctly in protover subsystem; only use when pro...2020-06-13T15:23:47ZNick Mathewsonprop249: advertise support correctly in protover subsystem; only use when protover support advertisedIn the link handshake and in the protover list, we should advertise support for CREATE2V and CREATED2V.
In the protover list, we should advertise support for fragmented EXTEND cells.
In the protover list, we should advertise support fo...In the link handshake and in the protover list, we should advertise support for CREATE2V and CREATED2V.
In the protover list, we should advertise support for fragmented EXTEND cells.
In the protover list, we should advertise support for our temporary testing handshake.Tor: unspecified