On Windows, paths can have a "prefix", like `C:` or
`\\server\share`. Attempts to get metadata for these prefixes
appear to fail with `ERROR_INVALID_FUNCTION`, since they are not
files.
This patch teaches fs-mistrust about prefixes on Windows, and tells
it that attempts to find their metadata are allowed to fail.
Doing this may solve part of #557.
Whereas previously we would say:
```
target/debug/arti: error: invalid escape character in string: `Z` at line 9 column 14 in ../../.config/arti/arti.toml
```
we now say:
```
target/debug/arti: error: invalid escape character in string: `Z` at line 9 column 14 in ../../.config/arti/arti.toml (If you wanted to include a literal \ character, you need to escape it by writing two in a row: \\)
```
The implementation is a bit of a hack, I'm afraid, but I don't think
it's all that bad.
Closes#549.
We need
60b874308e6792a73cc00517a60bbef60a12e3cc
Mixed type arrays (#358)
for a test case in tor-config.
While we're here, drop the dupe entry in tor-config.
(In principle we could make this increase only in tor-config's
dev-dependencies, but that seems unnecessarily fiddly.)
This commit largely follows the example for resolve_alternative_specs.
The difference is that there are two fields, so we use a macro to
avoid recapitulating the field names.
This is not interesting to the user, and violates some of our
safe-logging rules (like "Don't log at info for each user request"
and "don't log ports").
As per
https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/682#note_2830860
And subsequent IRC discussion.
Having done the work as per review comments, I don't much like the
result. It's quite un-ergonomiuc. If we can't have fs autodetection,
I think syntactic autodetection within sources.rs would be nearly as
nice.
However, I seem to be outvoted. At least the externally visible
functionality (of an arti binary, say) is reasonably ergonomic.
The parameter to FileWatcher::new is not a polling time fallback; it
is a "debounce time". Events are always delayed by at least this
much.
10s is much too long for this. 1s is more appropriate.
We're going to need to do config file reading in two phases.
Right now this isn't actually necessary, because the set of files
is fixed since we don't support dynamically scanning directories.
But the new API will be needed in a moment.
Code motion and API changes, but no overall functional change.
Review with `git show -b` may be helpful.
The new API also provides for dealing with directories, but right now
that doesn't happen.
The previous approach (inherited from the API of notify) was kind of
odd.
Soon we are going to want to be able to drop the watcher and replace
it. That really wants the same object to contain all the things that
ought to be dropped together. (notify's watchers stop generating
events and give EOF on the channel, when dropped.)
These blocks were in the wrong order.
Previously, if you tried to turn on process hardening in the config
and then reloaded rather than restarting, it wouldn't take effect.
At one point in this MR I thought I was going to want this for
arti::cfg::ListenConfig (which we don't want to be Default).
In fact ListenConfig is being handled specially, but having written
this function it seemed sensible to keep it. Since resolve_option
becomes a wrapper for it, the existing tests exercise it.
Making ChannelPaddingInstructions::default() accurately reflect the
initial state of the reactor's padding timer simplifies the code
somewhat.
(When padding is wanted, parameters are computed and inserted
explicitly, so the only change is that if we start out dormant, we
defer setting the timer parameters until necessary.)
As per
https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/657#note_2827249
Get rid of unneeded constructor.
We never need to use hardcoded reduced padding parameters during
negotiation cell construction. If we are using reduced padding
parameters, the layers which decide this have netparams to use.
Prompted by
https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/657#note_2826092
The network consensus parameters use (0,0) to mean "no padding"
(which is not the same as (0,0) means in a PADDING_NEGOTIATE cell).
Representing "no padding" this way is actually quite convoluted and
un-Rustic. Ensure that we convert (0,0) to None, and do the primary
logic in Option.
This gets rid of many Result(). Many parameters are renamed.
Test cases of the now-impossible branch are removed.
Deleting the match from padding_parameters will come in a moment.
I've split off that commit since it has much whitespace noise.
for now, change the error type to Void.
A "transient" error is one that does not indicate a true failure,
but rather an _expected_ need to retry. When we hit one of these,
we do not count it against the total number of permitted failures.
(We do impose a higher limit on "real failures plus transient
failures", though, to prevent infinite loops in the event of a
programming error.
Closes#517.
This is actually a general facility for inserting locally-generated
cells into the outgoing stream.
It doesn't seem to be possible to do this without adding an additional
condition check to the reactor, since we need to insert it into the
right place in the stream, giving it priority over data, and only
using it up if there was room in the output.
We don't engage this machinery yet, because nothing sets
special_outgoing.
Now all the information is plumbed to the right place, and we can
actually decide if we're sending padding.
Additionally, we conditionalise sending timing parameters on whether
padding is actually enabled, so in dormant mode we do not generate
updates (broadcast to all channels) just to reconfigure unused timing
parameters.
Change ChannelsParams::initial_update to compare fields with their
default values, and, if they're the same as the default, not to
include them in the returned update.
And if that update is then empty, return None.
The overall effect is to avoid the call to chan.reparameterize if
we're using the builtin default parameters, which is usual.
This arranges that the ChannelsParams we have retain, and which we
send to every newly created channel, actually has the right
parameters, even if they're not the default.
Now that the code that actually handles the netdir information can
cope with its lack, we can change the types of the various netdir
parameters and get rid of the foolish Bugs.
Now we actually honour the configuration variable.
However, when it is set to None, we lack proper handling. This will
be done bh turning None into 0,0 and then treating that as disabled.
There is a TODO for that.
Note that we *still* don't actually do or negotiate padding.
Move some logic out of reconfigure_general into what was
update_padding_parameters_from_netdir, and rename that function.
We're going to want to call this twice, shortly...
* Move out the PaddingParametersBuilder
* Have it handle missing netdir, though we currently always pass Ok
* Have it handle the error cases
It still ignores the config for now.
No overall functional change.
"git show -b" may be a useful way to review the changes in what
becomes "padding_parameters".
Now that we make an extract from the incoming NetDir, we can move the
padding parameters computation to after we take the lock.
This will be necessary for it to be able to depend on the config and
dormancy, records of which are protected by the chanmgr lock.
Channel padding depends on what the channel is being used for. We
therefore need to let the channel code know this information.
The implementation of the per-channel padding control logic will be in
the new note_usage function, which for now is simply a stub.
A future commit will introduce a `PaddingControlState` which lives in
the channel frontend; consult the doc comment for that type to see why
the plumbing through the channel manager terminates in the channel
frontend.
Ian Jackson
Nick Mathewson
Ian Jackson
Yuan Lyu
trinity-1686a
eta