| Age | Commit message (Collapse) | Author |
|---|
|
Declare support for the onion service introduction point denial of
service extensions, when building tor with Rust.
Fixes bug 34248; bugfix on 0.4.2.1-alpha.
|
|
Declare support for the new Relay=3 IPv6 extend protocol,
in C and Rust.
Part of 33226.
|
|
As recommended by the tor directory specification.
Fixes bug 33285; bugfix on 0.4.0.1-alpha.
|
|
|
|
|
|
|
|
By binding the protover numbering to specific padding machines, we can make
our padding negotiation simpler. We probably should have done this in the
first place.
This has the side effect that earlier 0.4.1.x-alpha clients won't negotiate
with 0.4.1.x-stable relays, and 0.4.1.x-stable clients won't negotiate with
earlier 0.4.1.x-alpha relays (or 0.4.0.x relays). Since we don't support
alphas after the stable is released, this is fine, so long as it gets in
before the first stable of 0.4.1.x.
|
|
|
|
See proposal 289 section 4.3 for more details.
It describes the flow control protocol at the circuit and stream level. If
there is no FlowCtrl protocol version, tor supports the unauthenticated flow
control features from its supported Relay protocols.
At this commit, relay will start advertising FlowCtrl=1 meaning they support
authenticated SENDMEs v1.
Closes #30363
Signed-off-by: David Goulet <dgoulet@torproject.org>
|
|
|
|
Trivial merge: a blank line was removed between 0.3.4 and 0.3.5.
|
|
|
|
This commit also explicitly set the value of the PRT enum so we can match/pin
the C enum values to the Rust one in protover/ffi.rs.
Fixes #29631
Signed-off-by: David Goulet <dgoulet@torproject.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
This helps us to determine if a middle node can pad to us or not.
Co-authored-by: George Kadianakis <desnacked@riseup.net>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
(I messed up the merge in 289a7dbac32a981897e12a3c250f0b6c67eec809.)
|
|
This file was moved in 97b15a1d7c51764888d2172711e3f3a71fb01916
and moved again in e7f5f48d68553206b95cbb4f610702c887500124.
|
|
|
|
|
|
|
|
|
|
|
|
This is unnecessary just to get an empty string, there's Default::default().
Fix on 8fff331bb095dc6f5e2fe2ecfc9ab08ea9e2fe97.
|
|
Only the final crate needs to be a `staticlib`, no need for all the
intermediate steps to produce staticlibs!
|
|
Unfortunately Cargo doesn't actually parse these! Cargo should probably
print a warning saying they're not used...
|
|
It looks to be the case that Rust's standard allocator, jemalloc, is
incompatible with sanitizers. The incompatibility, for whatever reason,
seems to cause segfaults at runtime when jemalloc is linked with
sanitizers.
Without actually trying to figure out what's going on here this commit
instead takes the hammer of "let's remove jemalloc when testing". The
`tor_allocate` crate now by default switches to the system allocator
(eventually this will want to be the tor allocator). Most crates then
link to `tor_allocate` ot pick this up, but the `smartlist` crate had to
manually switch to the system allocator in testing and the `external`
crate had to be sure to link to `tor_allocate`.
The final gotcha here is that this patch also switches to
unconditionally passing `--target` to Cargo. For weird and arcane
reasons passing `--target` with the host target of the compiler (which
Cargo otherwise uses as the default) is different than not passing
`--target` at all. This ensure that our custom `RUSTFLAGS` with
sanitizer options doesn't make its way into build scripts, just the
final testing artifacts.
|
|
|
|
This is already checked elsewhere.
|
|
The result of CString::into_raw() is not safe to free
with free() except under finicky and fragile circumstances
that we definitely don't meet right now.
This was missed in be583a34a3815c2c10e86094ab0610e4b7f9c869.
|
|
Fortunately with the current callers it couldn't happen in practice.
Fix on d1820c1516a31a149fc51a9e5126bf899e4c4e08.
|
|
Resolve conflicts due to rustfmt, and run rustfmt on the merged code.
|
|
|
