| Commit message (Collapse) | Author | Age | Files | Lines |
| ... | |
| | | | |
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | | |
This commit adds a unit test that checks if an empty value is parsed
properly.
It fixes the coverage in `crates/tor-ptmgr/src/ipc.rs:120`.
|
| | | |
| | |
| | |
| | |
| | | |
This commit adds a test which checks for a missing value in an SMETHOD
argument.
|
| | | |
| | |
| | |
| | |
| | | |
This commit adds a unit test to the `tor-ptmgr` crate, which checks for
forbidden `=` signs while reading a value.
|
| | | |
| | |
| | |
| | |
| | | |
This commit adds a unit test to the `tor-ptmgr` crate, which checks if
arguments are terminated with a backslash, which is forbidden.
|
| | | |
| | |
| | |
| | |
| | | |
This commit adds a unit test that checks if all octal escape sequences
are treated as an unsupported error.
|
| |/ /
| |
| |
| |
| | |
This commit adds a test to the `tor-ptmgr` crate, which increases the
test coverage by checking for escape sequences in values.
|
| |\ \
| |/
|/|
| |
| | |
Begin working on configuration logic for onion services
See merge request tpo/core/arti!1557
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | |
| |
| |
| |
| | |
Don't make people say "Dangerous!" in the configuration, document
the formats, and make the strings case-insensitive.
|
| | | |
|
| | | |
|
| | |
| |
| |
| |
| | |
Also, allow nonempty ranges starting with 0- and implement Eq and
PartialEq.
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | |
| |
| |
| | |
Note a few issues encountered while doing so.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| | |
For rate-limiting, we make it optional. If it isn't set, we don't
tell the intro to rate-limit.
We condense our two max-streams options into one. We had two
options here because we were looking for feature parity with C, but
I think I had misunderstood what C provides.
|
| | | |
|
| | | |
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
I'm calling this a "reverse proxy" since I think a lot of folks like
that terminology, though I'm not personally a huge fan. Calling it
"`tor-hsproxy`" would IMO confuse people more about what kind of proxy
it was.
This is a separate crate from `tor-hsservice` because it's logically
at a different level: if you're writing a little embedded onion
service, you don't need this code.
Right now there is only configuration logic here.
|
| | | |
|
| |\ \
| | |
| | |
| | |
| | | |
tor-hsservice: Use the new IPT change notifier API.
See merge request tpo/core/arti!1576
|
| | | | |
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
The reactor events are no longer received on the same channel, so we
don't need the `Event` enum or the old `Publisher` APIs any more.
Svc config changes are received on a wseparate `postage::watch` channel,
whereas IPT changes are detected through the `IptsPublisherView`.
The publisher will (eventually) be informed of keystore changes through
another `postage::watch` channel.
|
| | | |
| | |
| | |
| | |
| | | |
If multiple config changes happen in quick succession, we don't want the
publisher to publish a new descriptor for every single one.
|
| | | | |
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
This makes the publisher watch for IPT changes using the
`IptsPublisherView` added in arti#1023 (instead of waiting for an
`Event::NewIntroPoints`. The `Event` enum will soon be replaced by
multiple `postage::watch` channels, one for every type of change it
needs to react to).
|
| | | | |
|
| |\ \ \
| | | |
| | | |
| | | |
| | | | |
Switch to FixedCapacityVec from crates.io
See merge request tpo/core/arti!1563
|
| | | | | |
|
| |\ \ \ \
| |_|/ /
|/| | |
| | | |
| | | | |
Rebased attempt to merge gsoc2023 examples
See merge request tpo/core/arti!1574
|
| | | | |
| | | |
| | | |
| | | | |
I have no idea why these became necessary.
|
| | | | | |
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Put a last_descriptor_expiry_including_slop into the IptSet.
Define who is responsible for which data.
The code at the sites that interacts with this needs to be bodged, to
make it still compile. That code is wrong, and the new API for
sharing the state doesn't exist yet.
|
| | | | | |
|
| | |/ /
|/| |
| | |
| | |
| | | |
This is going to be complicated enough we probably want it split out
of the publisher.
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
The descriptor publisher reactor was (incorrectly) only keeping track of
the "current" and "previous" time periods.
The reactor now maintains a list of all relevant time periods (obtained
from `Netdir::hs_all_time_periods`).
|
| | | |
| | |
| | |
| | |
| | | |
We don't need to build the `Descriptor` for each time period (it
contains TP-agnostic information).
|
| |/ /
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This was based on the incorrect assumption there would be an external
source notifying the reactor of time period changes.
Time period changes will be handled in the consensus change handler of
the reactor.
Prompted by https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/1545#note_2935668
|
| | | |
|