| Commit message (Collapse) | Author | Age | Files | Lines |
| ... | |
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
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.
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
This patch allows us to compile the fs-mistrust tests on Windows where
the `trust_no_group_id()` method is unavailable.
See: tpo/core/arti#557.
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Since we are not going to test symlink creation on Windows we remove
this code from the testing module.
See: tpo/core/arti#557.
|
| | |/ /
|/| |
| | |
| | | |
See: tpo/core/art#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.
|
| |\ \
| | |
| | |
| | |
| | | |
fs-mistrust: Handle windows prefixes specially.
See merge request tpo/core/arti!698
|
| | | | |
|
| | |/
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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.
|
| |\ \
| | |
| | |
| | |
| | | |
Apply safelog to more of the things that we log
See merge request tpo/core/arti!693
|
| | | | |
|
| | | |
| | |
| | |
| | |
| | | |
Also, note why we aren't hiding the addrs that we're listening on
here.
|
| | | |
| | |
| | |
| | |
| | |
| | | |
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").
|
| | | |
| | |
| | |
| | | |
These aren't interesting to the user.
|
| | | | |
|
| | | |
| | |
| | |
| | |
| | | |
We now log connection attempts at debug!, and mark relay target
addresses as sensitive.
|
| |\ \ \
| | | |
| | | |
| | | |
| | | | |
tor-config: tests: Apply standard lint block in sources.rs
See merge request tpo/core/arti!694
|
| | | | |
| | | |
| | | |
| | | | |
Fixes a spurious clippy warning on nightly, about a dbg!
|
| |\ \ \ \
| | | | |
| | | | |
| | | | |
| | | | | |
arti: running_as_setuid: fix MacOs build
See merge request tpo/core/arti!697
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
libc::getuid and geteuid are marked unsafe, even though I think they
could be safe. So the previous code didn't build.
|
| |\ \ \ \ \
| |/ / / /
|/| | | |
| | | | |
| | | | | |
Clean up EstablishIntro cell
See merge request tpo/core/arti!648
|
| | | |_|/
| |/| | |
|
| |/ / /
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
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.)
|
| | | |
| | |
| | |
| | |
| | | |
As per
https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/602#note_2830847
|
| | | |
| | |
| | |
| | |
| | | |
Prompted by
https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/602#note_2830848
|
| | | |
| | |
| | |
| | |
| | | |
Prompted by
https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/602#note_2830766
|
| | | | |
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | | |
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 will allow us to handle new kinds of warnigns etc.
|
| | | |
| | |
| | |
| | | |
We're going to want the to use the same type for deprecated keys.
|
| | | | |
|
| | | | |
|
| |\ \ \
| |/ /
|/| |
| | |
| | | |
arti: Raise the default console log severity to "info"
See merge request tpo/core/arti!692
|
| | |/
| |
| |
| |
| | |
Previously we logged at "debug", but that's not meant to
user-facing.
|
| | | |
|
| | |
| |
| |
| |
| | |
FoundConfigFile existed to hide something that ConfigurationSource now
exposes.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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.
|
| | | |
|
| | |
| |
| |
| | |
I think this ought to be exhaustive.
|
| | |
| |
| |
| |
| |
| |
| |
| | |
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.
|
| | |
| |
| |
| | |
Fixes #474 aka #271
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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.
|
| | |
| |
| |
| |
| | |
We're going to want this functionality, which isn't in the stable
stdlib.
|