| Commit message (Collapse) | Author | Age | Files | Lines |
| ... | |
| |\ \ \ \ \
| |/ / / /
|/| | | |
| | | | |
| | | | | |
Add missing semver breaking changes
See merge request tpo/core/arti!3402
|
| | | | | | |
|
| |/ / / / |
|
| |\ \ \ \
| |/ / /
|/| | |
| | | |
| | | |
| | | |
| | | | |
arti: Remove now-needless cognitive_complexity exceptions
Closes #2226
See merge request tpo/core/arti!3397
|
| |/ / /
| | |
| | |
| | |
| | |
| | |
| | | |
Apparently the http_connect refactoring made these no longer
trigger.
Closes #2226
|
| |\ \ \
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Implement HTTP CONNECT proxy support in Arti.
Closes #2221
See merge request tpo/core/arti!3391
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
We can't remove them all, since X-Tor-Stream-Isolation is recognized
by C-Tor. I've added a non-deprecated Tor-Stream-Isolation
that works indepenently.
|
| | | | | |
|
| | | | | |
|
| | | | | |
|
| | | | | |
|
| | | | | |
|
| | | | | |
|
| | | | | |
|
| | | | | |
|
| | | | | |
|
| | | | | |
|
| | | | | |
|
| | | | | |
|
| | | | | |
|
| | | | | |
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
With his commit, our SOCKS ports now accept both SOCKS
and HTTP CONNECT requests, per proposal 365.
There are still some infelicities, marked with
"XXXX" or "TODO".
I've tested this with curl, though, and it works. :)
Typo-fixes-by: Gabriela Moldovan <[email protected]>
|
| | | | |
| | | |
| | | |
| | | |
| | | | |
This will let us speak HTTP CONNECT as well; there is a stub
for initiating an http proxy.
|
| | | | | |
|
| | | | |
| | | |
| | | |
| | | | |
This will let us implement bilingual HTTP proxies.
|
| | | | |
| | | |
| | | |
| | | | |
This is _all_ renaming and comment adjustments.
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
We want to abstract every part of this code that knows that it's
speaking SOCKS, so that we can in turn add a new proxy type.
Note that several methods and types here have names that are no
longer appropriate for their functionality. I'll revise those in a
later commit.
|
| | | | |
| | | |
| | | |
| | | |
| | | | |
(I'm not sure why this wasn't already done, but let's do it as a
separate MR.)
|
| | | | |
| | | |
| | | |
| | | | |
I'm about to add another proxy type.
|
| |\ \ \ \
| | | | |
| | | | |
| | | | |
| | | | | |
ci: Add needs to almost all jobs.
See merge request tpo/core/arti!3370
|
| |/ / / /
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
This also updates some needs statements that existed to order jobs that
did not actually have a dependency on each other.
The idea here is to run everything with as much parallelism as possible,
and if that parallelism causes problems, we should ideally solve it by
adding more runner capacity, or taking a closer look at what the actual
problem is.
|
| |\ \ \ \
| | | | |
| | | | |
| | | | |
| | | | | |
ci: Enable opentelemetry feature in arti-extra build.
See merge request tpo/core/arti!3392
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
I am interested in enabling opentelemetry in chutney tests to enable
easier debugging of failures that pop up in CI.
|
| |\ \ \ \ \
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
proto: Avoid identifying relay circuits using TunnelId
See merge request tpo/core/arti!3395
|
| |/ / / / /
| | | | |
| | | | |
| | | | | |
We replaced TunnelId with UniqId in the relay code a while ago.
|
| |\ \ \ \ \
| |_|/ / /
|/| | | |
| | | | |
| | | | | |
arti-relay: Use `Void` for `TorRelay::run`
See merge request tpo/core/arti!3394
|
| |/ / / / |
|
| |\ \ \ \
| |/ / /
|/| | |
| | | |
| | | | |
relay: Channel initiator authentication code
See merge request tpo/core/arti!3389
|
| | | | |
| | | |
| | | |
| | | | |
Signed-off-by: David Goulet <[email protected]>
|
| | | | |
| | | |
| | | |
| | | | |
Signed-off-by: David Goulet <[email protected]>
|
| | | | |
| | | |
| | | |
| | | | |
Signed-off-by: David Goulet <[email protected]>
|
| | | | |
| | | |
| | | |
| | | | |
Signed-off-by: David Goulet <[email protected]>
|
| | | | |
| | | |
| | | |
| | | | |
Signed-off-by: David Goulet <[email protected]>
|
| | | | |
| | | |
| | | |
| | | | |
Signed-off-by: David Goulet <[email protected]>
|
| | | | |
| | | |
| | | |
| | | | |
Signed-off-by: David Goulet <[email protected]>
|
| | | | |
| | | |
| | | |
| | | | |
Signed-off-by: David Goulet <[email protected]>
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
This is only done if we kept the AUTH_CHALLENGE cell and we have relay
identities. In other words, this is only when the UnverifiedChannel was
created from a RelayInitiatorHandshake.
Note: The check_internal() function is too large and should be
refactored in smaller pieces.
Note: It is also likely that we need to split UnverifiedChannel and
VerifiedChannel as it is getting client or relay members. Not great.
Signed-off-by: David Goulet <[email protected]>
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
The client and relay channel builder don't share anything and return
different objects hence the seperation.
Furthermore, this seperation avoids having the client ChanMgr ability to
launch relay channels.
Signed-off-by: David Goulet <[email protected]>
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
This is a intermediary object between tor-chanmgr and tor-proto that is
when building a relay channel, those keys/certs need to be set in the
ChannelBuilder so the tor-proto can use them to authenticate.
We avoid that way making tor-proto depending on tor-keymgr for the
ultimate goal to avoid tor-proto to have access to all the keys in the
KeyMgr.
Future commits will introduce a relay channel builder which will use
that object to set the keys.
Signed-off-by: David Goulet <[email protected]>
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
This commit only adds a struct holding all the authentication data that
needs to be built during the verification process after all handshake
cells needed for authentication have been sent.
It lives in the VerifiedChannel struct so it can be used to build the
AUTHENTICATE cell and be sent before the NETINFO.
Signed-off-by: David Goulet <[email protected]>
|