Trac issueshttps://gitlab.torproject.org/legacy/trac/-/issues2020-06-13T15:42:53Zhttps://gitlab.torproject.org/legacy/trac/-/issues/29018Make all statistics depend on ExtraInfoStatistics2020-06-13T15:42:53ZteorMake all statistics depend on ExtraInfoStatisticsLike #29017, when a user sets ExtraInfoStatistics 0, they probably don't want any statistics in their extra-info document.Like #29017, when a user sets ExtraInfoStatistics 0, they probably don't want any statistics in their extra-info document.Tor: 0.4.1.x-finalteorteorhttps://gitlab.torproject.org/legacy/trac/-/issues/29017PaddingStatistics should be disabled when ExtraInfoStatistics is 02020-06-13T15:36:26ZteorPaddingStatistics should be disabled when ExtraInfoStatistics is 0The man page entry for PaddingStatistics says that it is disabled when ExtraInfoStatistics is 0. But that isn't the case: the statistics are published regardless of ExtraInfoStatistics.
As far as I can tell, PaddingStatistics are collec...The man page entry for PaddingStatistics says that it is disabled when ExtraInfoStatistics is 0. But that isn't the case: the statistics are published regardless of ExtraInfoStatistics.
As far as I can tell, PaddingStatistics are collected on bridges, but the man page says "Relays only."Tor: 0.3.4.x-finalteorteorhttps://gitlab.torproject.org/legacy/trac/-/issues/28305Include client numbers even if we think we got reports from more than 100% of...2020-06-13T18:09:30ZKarsten LoesingInclude client numbers even if we think we got reports from more than 100% of all relaysThe estimated fraction of reported user statistics from relays has reached 100% and even went slightly beyond that number to 100.294% on 2018-10-27 and 100.046% on 2018-10-28.
The effect is that we're excluding days when this happened f...The estimated fraction of reported user statistics from relays has reached 100% and even went slightly beyond that number to 100.294% on 2018-10-27 and 100.046% on 2018-10-28.
The effect is that we're excluding days when this happened from statistics, because we never thought this was possible:
```
WHERE a.frac BETWEEN 0.1 AND 1.0
```
However, I think this is most likely a rounding error somewhere, not a general issue with the approach. Stated differently, it seems wrong to include a number with a fraction of reported statistics of 99.9% but not one where that fraction is 100.1%.
I suggest that we drop the upper limit and change the line above to:
```
WHERE a.frac >= 0.1
```
We'll be replacing these statistics by PrivCount in the medium term anyway.
However, simply excluding data points doesn't seem like an intuitive solution.
Thoughts?Karsten LoesingKarsten Loesinghttps://gitlab.torproject.org/legacy/trac/-/issues/27199panic inside rust extern "C" function is undefined behavior2020-06-13T15:29:38ZTracpanic inside rust extern "C" function is undefined behavior`panic="abort"` needs to be set for all profiles in Cargo.toml, at least until the upstream bug is fixed: https://github.com/rust-lang/rust/issues/52652
This is already set for `[profile.release]` builds, but not for the others.
**Trac...`panic="abort"` needs to be set for all profiles in Cargo.toml, at least until the upstream bug is fixed: https://github.com/rust-lang/rust/issues/52652
This is already set for `[profile.release]` builds, but not for the others.
**Trac**:
**Username**: cyberpunksTor: 0.3.4.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/26958Privcount blinding and encryption: run clippy on travis rust nightly2020-06-13T15:28:48ZteorPrivcount 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/legacy/trac/-/issues/26378test_rust.sh fails on src/rust/crypto2020-06-13T15:26:43ZGeorge Kadianakistest_rust.sh fails on src/rust/cryptoThe latest travis builds fail on the rust tests after #26258 got merged (i guess). Here are some fails:
```
--> external/crypto_digest.rs:74:1
|
74 | const N_DIGEST_ALGORITHMS: usize = DIGEST_SHA3_512 as usize + 1;
| ^^^^^^^^^^^...The latest travis builds fail on the rust tests after #26258 got merged (i guess). Here are some fails:
```
--> external/crypto_digest.rs:74:1
|
74 | const N_DIGEST_ALGORITHMS: usize = DIGEST_SHA3_512 as usize + 1;
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
= note: #[warn(dead_code)] on by default
warning: type alias is never used: `smartlist_t`
--> external/crypto_digest.rs:120:1
|
120 | type smartlist_t = Stringlist;
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
warning: constant item is never used: `N_DIGEST_ALGORITHMS`
--> external/crypto_digest.rs:74:1
|
74 | const N_DIGEST_ALGORITHMS: usize = DIGEST_SHA3_512 as usize + 1;
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
= note: #[warn(dead_code)] on by default
warning: type alias is never used: `smartlist_t`
--> external/crypto_digest.rs:120:1
|
120 | type smartlist_t = Stringlist;
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Finished dev [unoptimized + debuginfo] target(s) in 3.39 secs
Running /home/travis/build/torproject/tor/tor-0.3.4.2-alpha-dev/_build/src/rust/target/debug/deps/external-99409f0e61b6d8c2
```
See https://api.travis-ci.org/v3/job/392350333/log.txt etc.Tor: 0.3.4.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/26267export rand from the crypto crate2020-06-13T15:26:11ZIsis Lovecruftexport rand from the crypto crateIn #26107, it appears I forgot to add
```
pub mod rand;
```
in `src/rust/crypto/lib.rs`. This is possibly causing #26245.In #26107, it appears I forgot to add
```
pub mod rand;
```
in `src/rust/crypto/lib.rs`. This is possibly causing #26245.Tor: 0.3.4.x-finalIsis LovecruftIsis Lovecrufthttps://gitlab.torproject.org/legacy/trac/-/issues/26214Check stream SENDME against max2020-06-13T15:26:01ZMike PerryCheck stream SENDME against maxIn connection_edge_process_relay_cell() under the RELAY_COMMAND_SENDME handling, we check the circuit-level sendme against the window START_MAX, but we do not check the stream level SENDME against any max
This means that an attacker can...In connection_edge_process_relay_cell() under the RELAY_COMMAND_SENDME handling, we check the circuit-level sendme against the window START_MAX, but we do not check the stream level SENDME against any max
This means that an attacker can send as many stream-level sendme's on a circuit as they like, inflating the stream window as large as they like. This might be a serious OOM bug, but the circuit level SENDME check should prevent that, I think.
Even so, it would be nice to fix this in 0.3.4, so that the vanguards script's detection of invalid/dropped circuit data is more accurate.Tor: 0.3.4.x-finalMike PerryMike Perryhttps://gitlab.torproject.org/legacy/trac/-/issues/26109our crypto::digests crate isn't actually exported2020-06-13T15:25:43ZIsis Lovecruftour crypto::digests crate isn't actually exportedWe should probably make it `pub` somehow if we intend to use it.We should probably make it `pub` somehow if we intend to use it.Tor: 0.3.4.x-finalIsis LovecruftIsis Lovecrufthttps://gitlab.torproject.org/legacy/trac/-/issues/26108the FFI functions in crypto_rand.rs aren't actually exported2020-06-13T15:25:43ZIsis Lovecruftthe FFI functions in crypto_rand.rs aren't actually exportedTor: 0.3.4.x-finalIsis LovecruftIsis Lovecrufthttps://gitlab.torproject.org/legacy/trac/-/issues/26107move rand crate into parent crypto crate2020-06-13T15:25:42ZIsis Lovecruftmove rand crate into parent crypto crateThe crate at src/rust/rand should probably actually live at src/rust/crypto/randThe crate at src/rust/rand should probably actually live at src/rust/crypto/randTor: 0.3.4.x-finalIsis LovecruftIsis Lovecrufthttps://gitlab.torproject.org/legacy/trac/-/issues/26106bump rand dependency to 0.5.0-pre.22020-06-13T15:25:42ZIsis Lovecruftbump rand dependency to 0.5.0-pre.2This is blocking #23886, because the `rand_core::RngCore` and `rand::Rng` traits resolve as being different, because `curve25519-dalek` needs to use `0.5.0-pre.2` because it added `impl CryptoRng for OsRng` (which we also probably want b...This is blocking #23886, because the `rand_core::RngCore` and `rand::Rng` traits resolve as being different, because `curve25519-dalek` needs to use `0.5.0-pre.2` because it added `impl CryptoRng for OsRng` (which we also probably want but I did a workaround in #25508).Tor: 0.3.4.x-finalIsis LovecruftIsis Lovecrufthttps://gitlab.torproject.org/legacy/trac/-/issues/25705Refactor circuit_build_failed to separate build vs path failures2022-06-24T14:25:41ZMike PerryRefactor circuit_build_failed to separate build vs path failuresWe should not give up on the network, our TLS conn, or our guard in the event of path failures (which can happen if we're low on mds, and/or if the user set a bunch of path-restricting torrc options).
I think this might want to be a bac...We should not give up on the network, our TLS conn, or our guard in the event of path failures (which can happen if we're low on mds, and/or if the user set a bunch of path-restricting torrc options).
I think this might want to be a backport. It should also handle #25347.Tor: 0.3.3.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/25573Track half-closed stream IDs2022-03-22T13:18:09ZMike PerryTrack half-closed stream IDsIn order to eliminate a side channel attack described in https://petsymposium.org/2018/files/papers/issue2/popets-2018-0011.pdf ("DropMark" attack) we need a way to determine if a stream id is invalid.
Many clients (particularly Firefox...In order to eliminate a side channel attack described in https://petsymposium.org/2018/files/papers/issue2/popets-2018-0011.pdf ("DropMark" attack) we need a way to determine if a stream id is invalid.
Many clients (particularly Firefox) will hang up on streams that still have data in flight. In this case, Tor clients send RELAY_COMMAND_END when they are done with a stream, and immediately remove that stream ID from their valid stream mapping. The remaining application data continues to arrive, but is silently dropped by the Tor client. The result is that this ignored stream data currently can't be distinguished from injected dummy traffic with completely random stream IDs, and this fact can be used to mount side channel attacks.
A similar situation exists for spurious RELAY_ENDs.Tor: 0.3.4.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/25381Add crypto_rand_double_sign() in C and Rust2020-06-13T15:22:33ZteorAdd crypto_rand_double_sign() in C and RustWe need a function that returns 1.0 or -1.0 with equal probability, so we can avoid weird tricks that waste floating point precision.
Since we want to use this in the laplace and guassian distributions, it needs to be implemented in bot...We need a function that returns 1.0 or -1.0 with equal probability, so we can avoid weird tricks that waste floating point precision.
Since we want to use this in the laplace and guassian distributions, it needs to be implemented in both C and Rust.Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/24929Maybe load balance pinned middles?2020-06-13T15:20:47ZMike PerryMaybe load balance pinned middles?Roger pointed out that people may specify entire countries or multiple countries for #13837, and may be surprised that tor doesn't load balance properly in this case. We may want to do load balancing here, if the list of selected nodes e...Roger pointed out that people may specify entire countries or multiple countries for #13837, and may be surprised that tor doesn't load balance properly in this case. We may want to do load balancing here, if the list of selected nodes exceeds K for some K.Tor: 0.3.3.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/24778Mark prop#283 as Accepted2020-06-13T15:19:44ZteorMark prop#283 as AcceptedWe have merged all the spec changes and half the code, so we've definitely accepted this one.We have merged all the spec changes and half the code, so we've definitely accepted this one.Tor: 0.3.3.x-finalteorteorhttps://gitlab.torproject.org/legacy/trac/-/issues/24735Always check for the null address when calling address functions2020-06-13T15:19:28ZteorAlways check for the null address when calling address functionsThese address functions have never had return values:
* node_get_prim_dirport()
* node_get_pref_ipv6_orport()
We should make sure we always check for the null address when we call them.These address functions have never had return values:
* node_get_prim_dirport()
* node_get_pref_ipv6_orport()
We should make sure we always check for the null address when we call them.Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/24732Remove unused IPv6 DirPort code2020-06-13T15:19:26ZteorRemove unused IPv6 DirPort codeIPv6 DirPorts aren't used by Tor: clients use IPv4/IPv6 ORPorts, and relays use IPv4 DirPorts (and IPv4 ORPorts).
There is code that implements this algorithm in commit 36ba50c820 of my bug23975_tree branch.IPv6 DirPorts aren't used by Tor: clients use IPv4/IPv6 ORPorts, and relays use IPv4 DirPorts (and IPv4 ORPorts).
There is code that implements this algorithm in commit 36ba50c820 of my bug23975_tree branch.Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/24573rewrite_node_address_for_bridge() should set IPv6 preferences even if there ...2020-06-13T15:18:40Zteorrewrite_node_address_for_bridge() should set IPv6 preferences even if there is no rirewrite_node_address_for_bridge() should always set IPv6 preferences, even if there is only one of ri or rs. And it should always warn about them.
This goes back to commit c213f277cde in 0.2.8.2-alpha and commit 9e9edf71f7d in 0.2.4.5-a...rewrite_node_address_for_bridge() should always set IPv6 preferences, even if there is only one of ri or rs. And it should always warn about them.
This goes back to commit c213f277cde in 0.2.8.2-alpha and commit 9e9edf71f7d in 0.2.4.5-alpha.Tor: 0.3.3.x-final