Because we want to work more on ensuring that our semver stability
story is solid, we are _not_ bumping arti-client to 1.0.0 right now.
Here are the bumps we _are_ doing. Crates with "minor" bumps have
had API breaks; crates with "patch" bumps have had new APIs added.
Note that `tor-congestion` is not bumped here: it's a new crate, and
hasn't been published before.
```
tor-basic-utils minor
fs-mistrust minor
tor-config minor
tor-rtcompat minor
tor-rtmock minor
tor-llcrypto patch
tor-bytes patch
tor-linkspec minor
tor-cell minor
tor-proto minor
tor-netdoc patch
tor-netdir minor
tor-persist patch
tor-chanmgr minor
tor-guardmgr minor
tor-circmgr minor
tor-dirmgr minor
arti-client minor
arti-hyper minor
arti major
arti-bench minor
arti-testing minor
```
Since our last round of releases, these crates have had either
trivial changes, or changes that did not affect their APIs.
Therefore we are bumping their versions, but not changing which
versions of them other crates depend on.
This patch fixes a minor build error where we would call
`compact_home()` on Windows instead of `anonymize_home()` on our PathBuf
instance.
Additionally we change how the `arti_conf` path is constructed such that
we join the individual path components to ensure that no "/" ends up
being present on Windows where path's are separated by "\".
See: tpo/core/arti#555.
See: tpo/core/arti!700.
This patch shortens the duration of the `does_not_predict_old_ports`
test in the preemptive module. AppVeyor spawns its VMs/containers per
build, so the `Instant::now()` call returns a value smaller than `60 *
60 + 1` which causes the subtraction to overflow and thus panic.
Thanks to @trinity-1686a for the help here.
See: tpo/core/arti#563.
This patch comments out a method call to `trust_group()` as this method
is not available on all platforms that Arti builds on right now and thus
fails to compile there.
I have added a comment that the given call is not available on non-Unix
like platforms.
See: tpo/core/arti#557.
This patch disables `readable_ok()`, `multiple_errors()`, and
`check_contents()` as they all rely on permission issues on groups being
detected properly which is not the case on Windows right now.
See: tpo/core/arti#557.
This patch changes our `default_config()` test in `arti/src/cfg.rs` such
that we can define a number of known unrecognized options on different
platforms.
We mark the two keys "storage.permissions.trust_group" and
"storage.permissions.trust_user" as unknown on the Windows platform as
such features is not available using the ordinary Unix UID concept.
This patch also publicly exposes the `tor_config::load::DisfavouredKey`
and `tor_config::load::PathEntry` types and marks them as
non-exhaustive.
See: tpo/core/arti#450.
This patch refactors how we construct the `Mistrust` type in the tests
found in the fs-mistrust crate such that it is possible to construct an
instance of the `Mistrust` type using a set of operations available via
the `MistrustBuilder`'s methods.
We handle some of the portability issues found while testing this code
on Windows in the convenience function `mistrust_build()` instead of
having duplicated code in multiple test cases.
See: tpo/core/arti#557.
This patch adds a comment to the `link_rel()` function in fs-mistrust to
explain why we ignore symlink creation on the Windows platform.
See: tpo/core/arti#557.
This patch disables the simple_cases() test on non-Unix platforms and
hides the LinkType type import on non-Unix where we won't be testing
symbolic link features.
See: tpo/core/arti#557.
We have a test that tries to check that our outputs are the same as
those from `std::fs::canonicalize`. But on Windows, they aren't:
There, `canonicalize` also puts path prefixes into a "Verbatim"
form.
This patch tries to replicate that behavior for the test only. If
we find that it's unreliable, though, our best bet is probably to
revise or disable this check on Windows, rather than chasing
compatibility with `GetFinalPathNameByHandle`.
Should fix part of #557.
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.)
trinity-1686a
Ian Jackson
Ian Jackson
Nick Mathewson
Alexander Færøy
Arturo Marquez
Yuan Lyu