| Commit message (Collapse) | Author | Age | Files | Lines |
| ... | |
| | | | | | | |
|
| | | | | | | |
|
| | | | | | | |
|
| | | | | | | |
|
| | | | | | | |
|
| | | | | | | |
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
This will allow the PowManager to have a copy of RendRequestReceiver,
which is important to allow the PowManager update loop to control the
suggseted_effort updating.
|
| | | | | | | |
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
This makes the suggested_effort value a Arc<RwLock<Effort>>, which is
shared between the PowManager (as a reader) and the RendRequestReceiver
(as a writer), since the RendRequestReceiver has the information needed
to update the suggested_effort value.
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
The updated PoW control loop in prop362 requires this data structure to
be double ended, which BinaryHeap is not. I benchmarked [email protected]
against BTreeSet on a synthetic benchmark based on what I expected
typical load to look like, and found that BTreeSet performed much
better. It is additionally in the standard library, and is maintained,
which no third-party double ended priority queue crate seems to be.
Given that, BTreeSet seems like a reasonable thing to build on, although
we should provide metrics on the performance of this queue so operators
can let us know if it seems to be a problem in real-world use.
|
| |/ / / / /
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Since this will be used in a BTreeSet, we need to ensure that in
practice no two requests will be equal. Ordering by a combination of
effort and time received should be sufficient for this, and gives us the
behaviour we want.
|
| |\ \ \ \ \
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
Negotiate and use CGO.
Closes #1947 and #1945
See merge request tpo/core/arti!3069
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
This commit prevents us from ever deciding that another relay
supports CGO, which prevents us from trying to negotiate it.
It also adds an assertion to make sure that we haven't tried to
negotiate it.
We can remove this once we're ready to have CGO turned on:
right now it's blocked on being able to negotiate CC.
I'm adding this so we can merge this branch (so that I can stop
rebasing it.)
|
| | | | | | | |
|
| | | | | | | |
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
We now take an enum describing whether we are doing no negotiation,
HsV3 negotiation, or full negotiation. This lets us do away with
the notions of default relay crypto, and of declaring post-facto
that no negotiation has occurred.
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
Instead call it compatible_with_cgo, which is what we actually
care about in this context.
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | | |
Let's see if it works!
|
| | | | | | | |
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
Since these will be negotiated (or determined as part of negotiation)
they belong in HopSettings.
|
| | | | | | | |
|
| |\ \ \ \ \ \
| |/ / / / /
|/| | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
Apply tcyrus's patches from #2050
Closes #2050
See merge request tpo/core/arti!3104
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
`tor_llcrypto::pk::ed25519::PublicKey` is based on `ed25519_dalek::VerifyingKey`
and not `ed25519_dalek::SigningKey`.
|
| |/ / / / / |
|
| |\ \ \ \ \
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
tor-keymgr: Add err::Error::KeystoreNotConfigured
See merge request tpo/core/arti!3103
|
| |/ / / / / |
|
| | | | | |
| | | | |
| | | | |
| | | | | |
This was somehow accidentally deleted.
|
| | | | | | |
|
| | | | | | |
|
| | | |\ \ \
| | | | | |
| | | | | |
| | | | | | |
hyper-examples
|
| | | | | | | |
|
| | | | | | | |
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | | |
Previous comment was not clear. `is_fully_reachable` only gives false negatives, not false positives.
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | | |
We removed the while loop.
|
| | | | | | | |
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
The reason we prefer `rustls` in this case is because `rustls` provides
better portability then `native-tls` due to not being dependent on the system.
We have to explicitely set the root_cert because `rustls` does not use the
system CA Certs to remain portable.
|
| | | | | | | |
|
| | | | | | | |
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | | |
We will make a separate library for this.
|
| | | | | | | |
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
This example previously remained stuck in the while loop without any output, seeming as if this example is not working.
This because the method `is_fully_reachable` is no guarantee for the actual status of the onion service. It might return false while the service is actually reachable.
We added a timeout to not remain stuck in the loop.
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | | |
This directory had to be renamed because otherwise it would cause conflicts with the actual hyper crate in the CI pipeline.
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | | |
This example previously had errors trying to make a connection, this is solved now.
|
| | | | | | | |
|
| | | | | | | |
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
This example directory had a separate directory for each example. We can
simplify this by using binaries.
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | | |
This example made a request to a website which could deanonymize the user. We now use check.torproject.org instead.
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
This example demonstrates how to create a custom connector which can be injected
into a hyper client, to use hyper for Tor requests.
|
| | | | | | | |
|
| | | | | | | |
|