| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| ... | |
| | |
| |
| |
| |
| |
| | |
This type was returned by the public DownloadSchedule::builder
function. But the only thing that seems to have noticed that the type
name itself wasn't exported, was rustdoc. Hmmm.
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The new API is (roughly) as discussed in
https://gitlab.torproject.org/tpo/core/arti/-/issues/451
This is quite a large commit and it is not convenient to split it up.
It contains the following changes:
* Redo the list builder and accessor macros implemnetation,
including docs and tests.
* Change uses of define_list_config_builder. In each case:
- Move the docs about the default value to the containing field.
- Remove the other docs (which were just recapitulations, and
are now not needed since the ListBuilder is no longer public).
- Rewmove or replace `pub` in the define_list_builder_helper call,
so that the builder is no longer public.
- Change the main macro call site to use define_list_builder_helper.
- Add a call to define_list_builder_accessors.
* Make the module `list_builder` pub so that we have somewhere to
put the overview documentation.
* Consequential changes:
- Change `outer.inner().replace(X)` to `outer.set_inner(X)`
- Consequential changes to imports (`use` statements).
|
| | |
| |
| |
| |
| | |
This removes a caveat from the API and will be convenient for what is
coming.
|
| | |
| |
| |
| | |
The list accessor macro is going to want this.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| | |
Previously this field was differently named to its serde and to its
accessors. We are about to introduce a macro_rules macro which will
provide list accessors and we don't want that macro to have a field
renaming feature.
So stop renaming the field.
|
| |\|
| |
| |
| |
| | |
Fix config version
See merge request tpo/core/arti!482
|
| |/
|
|
| |
This matches Cargo.lock. I suspect a mismerge in arti!478.
|
| |\
| |
| |
| |
| |
| |
| | |
CfgPath overhaul
Closes #449
See merge request tpo/core/arti!478
|
| | |
| |
| |
| |
| |
| | |
Use MessagePack.
Signed-off-by: Ian Jackson <[email protected]>
|
| | |
| |
| |
| |
| |
| | |
And provide round-trip tests.
As per https://gitlab.torproject.org/tpo/core/arti/-/issues/371
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Document that this can contain either a string for expansion, or a
literal PathBuf not for expansion.
Rename the `from_path` method to `new_literal`: a very important
difference is whether it gets expanded - less important than the Rust
type. Also, now it takes `Into<PathBuf>`, which avoids a needless
clone.
(We don't change the API in `arti-client` because
`&tempfile::Tempdir()` doesn't implement `Into<PathBuf>`, so
`arti-client` has to have some new `as_ref` calls.)
Provide accessors `as_unexpanded_str` and `as_literal_path`. The
deserialisation already makes this part of the stable API,l so not
pvoding accessors seems just obstructive. They are useful for tests,
too.
Add tests for the new entrypoints, and for deserialisation of both
variants from TOML (via config, or directly) and JSON.
|
| | |
| |
| |
| |
| |
| |
| |
| | |
We introduce LiteralPath struct, so that a literal path deserialises
from
some_path = { literal: "actual path string" }
This makes the deserialisation unambiguous.
|
| | |
| |
| |
| |
| |
| | |
arti uses this. Somehow this seems to be enabled by some other thing
in the crate graph, but I found that adding a similar dependency to
another crate resulted in a `config` which doesn't compile.
|
| |\ \
| | |
| | |
| | |
| | | |
Second cut at a fs-mistrust crate.
See merge request tpo/core/arti!468
|
| | | | |
|
| | | | |
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | | |
This helps make it possible to use `SecureDir` (name pending) even
when we want to disable permissions checks. Otherwise, optional
permission checking would require users of this crate to maintain
separate code paths for the "check" and "don't check" cases.
|
| | | |
| | |
| | |
| | | |
This will make a "trust_everyone" easier to implement.
|
| | | | |
|
| | | |
| | |
| | |
| | |
| | | |
Some of our builders put root into gid 0, but getgroups() doesn't
actually give any result.
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
This required a bit of poking through the `users` crate, to mess
with the user and group dbs. The original goal was to "trust the
group with the same name as us", but it turned into a bit of a
production, since:
* We want to take our own name from $USER, assuming that matches
our uid. (Otherwise we want to ask getpwuid_r().)
* We only want to trust the group if we are actually a member of
that group.
* We want to cache this information.
* We want to test this code.
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Previously we would temporarily put self.resolved into an invalid
state by adding a path component that might be a symlink. With this
change, we create a new temporary path object (using Cow to avoid
unnecessary allocations) and only conditionally replace
self.resolved.
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | |
| | |
| | |
| | |
| | |
| | | |
The only way to get a SecureDir is by having checked a directory.
Once you have one, it encourages you to open and create files and
directories with the right permissions, and checks them for you.
|
| | | |
| | |
| | |
| | | |
Also, explain _why_ this is pretty important.
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
This crate is meant to solve #315 by giving a way to make sure that
a file or directory is only accessible by trusted users. I've tried
to explain carefully (in comments and documentation) what this crate
is doing and why, under the assumption that it will someday be read
by another person like me who does _not_ live and breathe unix file
permissions. The crate is still missing some key features, noted in
the TODO section.
It differs from the first version of the crate by taking a more
principled approach to directory checking: it emulates the path
lookup process (reading symlinks and all) one path change at a time,
thus ensuring that we check every directory which could enable
an untrusted user to get to our target file, _or_ which could
enable them to get to any symlink that would get them to the target
file.
The API is also slightly different: It separates the `Mistrust`
object (where you configure what you do or do not trust) from the
`Verifier` (where you set up a check that you want to perform on a
single object). Verifiers are set up to be a bit ephemeral,
so that it is hard to accidentally declare that _every_ object
is meant to be readable when you only mean that _some_ objects
may be readable.
|
| |\ \ \
| |_|/
|/| |
| | |
| | | |
Add a comment explaining what downgrade_dependencies is for.
See merge request tpo/core/arti!480
|
| | | | |
|
| |\ \ \
| | | |
| | | |
| | | |
| | | | |
update tls-api to 0.8.0
See merge request tpo/core/arti!479
|
| | | | |
| | | |
| | | |
| | | |
| | | | |
nix:0.4.2 is no longer a dependency
synstructure:0.12.0 is no longer required to build
|
| |/ / /
| | |
| | |
| | | |
and remove corresponding RUSTSEC from ignored list
|
| |\ \ \
| | | |
| | | |
| | | |
| | | | |
derive_builder: Use git dep everywhere, rather than cargo patch
See merge request tpo/core/arti!477
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
The `[patch]` approach causes the tree not to build when used as a
dependency, unless the `[patch]` is replicated into the depending
project.
Instead, replace our `derive_builer =` dependencies with a reference
to a specific git commit:
perl -i~ -pe 'next unless m/^derive_builder/; s#"(0\.11\.2)"#{ version = "$1", git = "https://github.com/ijackson/rust-derive-builder", rev = "ba0c1a5311bd9f93ddf5f5b8ec2a5f6f03b22fbe" }#' crates/*/Cargo.toml
Note that the commitid has changed. This is because derive_builder is
in fact a workspace of 4 crates. 3 of them are of interest to arti
itself (the 4th exists only for testing). So the same "add git
revision" treatment had to be done to the `derive_builder` and
`derive_builder_macro` crates. Each dependency edge involves a new
commit in the derive_builder workspace, since we can't create a git
commit containing its own commitid. (We want to use commits, rather
than a branch, so that what we are depending on is actually properly
defined, and not subject to the whims of my personal github
namespace.)
There are no actual code changes in derive_builder.
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
The arti crate itself is only used in benchmark and testing crate.
I think this sentence does not belong here.
Also extend retry-error description (from Architecture.md).
|
| | | | | |
|
| | | | | |
|
| |\ \ \ \
| |/ / /
|/| | |
| | | |
| | | |
| | | |
| | | | |
Upgrade various dependencies, now that we are MSRV 1.56
Closes #313 and #334
See merge request tpo/core/arti!476
|
| | | | |
| | | |
| | | |
| | | | |
This is no longer necessary. :)
|
| | | | | |
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Now that we require Rust 1.56, we can upgrade to AES 0.8. This
forces us to have some slight API changes.
We require cipher 0.4.1, not cipher 0.4.0, since 0.4.0 has
compatibility issues with Rust 1.56.
|
| | | | | |
|
| | | | | |
|
| | | | | |
|
