| Commit message (Collapse) | Author | Age | Files | Lines |
| ... | |
| | | |
| | |
| | |
| | |
| | | |
Needed for the chanmgr to be able to update existing channels with new
KIST settings read from the consensus.
|
| | | | |
|
| | | |
| | |
| | |
| | |
| | | |
This will enable us to update the channel's KIST configuration whenever
there is a change in the consensus or config.
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | |
| | |
| | |
| | |
| | |
| | | |
This is unfortunately necessary, because after the channel handshake, we
need to give the channel reactor a `StreamOps` handle to the underlying
stream.
|
| | | | |
|
| | | | |
|
| | | |
| | |
| | |
| | |
| | | |
We're about to add a trait bound that forces `MockTlsStream` to impl
`StreamOps`.
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Needed for cases where we wrap an object that implements `StreamOps` in
an external type, thereby losing access to the `StreamOps`
functionality. For example, during the channel handshake, we `.split()`
the stream that implements `StreamOps`, which leaves us with a
`SplitSink` and a `SplitStream`, neither of which implement `StreamOps`.
Getting a handle to the underlying object that implements `StreamOps`
(for example, a file handle) *before* the stream is `.split()` enables
us to use `StreamOps` to manipulate the underlying split stream.
This commit also introduces a special `UnsupportedStreamOpsHandle`,
which is a type that implements `StreamOps`, but always returns an
error. This type is meant to simplify error handling and usage, and is
meant to be used in cases where `StreamOps` is not supported. TODO: the
name of this type is pretty confusing (it's very similar to
`UnsupportedStreamOp`, which is an error type), and should probably be
renamed to something else (`NoOpStreamOpsHandle`,
`BrokenStreamOpsHandle`, `DummyStreamOpsHandle` come to mind...).
Note: this changes the `StreamOps` trait to be slightly different from
what I originally envisioned in !2660 and #1769
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Note: this commit makes `tor-proto` depend on `tor-netdir`
(because it adds a `KistParams` type that is buildable from
`NetParameters`, which is defined in `tor-netdir`).
Closes #1729
|
| | |/
|/|
| |
| |
| |
| | |
These are tentative, so I haven't added them to param-spec yet.
Part of #1729
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Previously, if r is Pending, `fut` is moved out of (stored in
`task.fut`), whereas if r is Ready, it is retained and then dropped at
the end of the loop iteration. This is quite subtle, and involves
`fut` being in a "maybe moved out of" state (which cannot be
represented in Rust's surface type system) after the block with the
`data` lock.
Let's write code that more clearly ensures that the compiler DTRT.
|
| | |
| |
| |
| |
| | |
This passes right now, but only because the lifetime of the `fut`
variable in `execute_until_first_stall` happens to be right.
|
| | | |
|
| | | |
|
| | | |
|
| | |
| |
| |
| | |
(We don't add it to the handful of unit tests that don't use an executor.)
|
| |\ \
| |/
|/|
| |
| |
| |
| | |
fs-mistrust: Facilities for file access
Closes #1746
See merge request tpo/core/arti!2707
|
| | |
| |
| |
| |
| | |
This approach makes it even less likely for people to store a
FileAccess for repeated use.
|
| | | |
|
| | | |
|
| | | |
|
| | |
| |
| |
| |
| |
| | |
When we're not bound to a CheckedDir, it doesn't make sense to
forbid following symlinks, so long as their targets are also
sensible.
|
| | | |
|
| | |
| |
| |
| | |
There is no reason for these to consume self.
|
| | | |
|
| | | |
|
| | |
| |
| |
| |
| | |
These are the methods which we'd like to give new options in #1746;
we can move other methods later if we want to.
|
| | |
| |
| |
| |
| | |
We're going to move functionality and configuration functions here
to implement #1746.
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| |/ |
|
| | |
|
| |
|
|
|
|
|
| |
There is no need for validation here. If any validation is required, it
will be handled by the calling code.
Prompted by https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/2672?commit_id=10845d5e6a06d4d9548d536846eb470128d8a7d4#note_3147517
|
| |
|
|
|
| |
No longer used, because we're now using `ParsedEd25519Cert` instead of
`KeyUnknownCert` to represent parsed but not yet validated certs.
|
| |
|
|
|
|
|
| |
This helps us get rid of our uses of `KeyUnknownCert`. Needed because
`KeyUnknownCert` can't readily be converted back to `EncodedEd25519Cert`
(while `ParsedEd25519Cert` *can* -- see the `certs` module from
`tor-relay-crypto`).
|
| | |
|
| |
|
|
|
|
|
| |
This will come in handy later on, when we start using these function in
conjunction with `KeyMgr::get_or_generate_key_and_cert`, which expects
the `make_certificate` callback to return a type that implements
`ToEncodableCert`.
|
| |
|
|
| |
Closes #1777
|
| |
|
|
|
|
| |
These will be the `ToEncodableCert`s we write to the keystore.
Part of #1777
|
| |
|
|
|
| |
This will enable us to retrieve it from the keystore as an `ErasedKey`
(side note, we should rename `ErasedKey` to `ErasedItem`).
|