This commit changes certain log messages to debug for recoverable errors
and a warn if all such attempts fail, in order to not clutter up the
info messages that end users get to see.
This function will be used to look up a relay by a set of LinkSpecs
given from an incoming HsDesc or INTRODUCE2 message. It differs
from other "lookup relay by IDs" functions in that it needs to be
able to return "here's a relay", "couldn't found a relay", or
"learned that this relay is impossible."
Closes#855: This is the only new API needed for ChanTarget
validation, I think.
Now ClientCirc is no longer `Clone`, and the things that need it
to be `Clone` instead return and use an Arc<ClientCirc>
We're doing this so that ClientCirc can participate in the RPC
system, and so that its semantics are more obvious.
Closes#846.
Thanks to the type system, this was a much simpler refactoring than
I had feared it would be.
This also moves the `extension` function out of `KeyType` because for
the C Tor key store, a key's file extension depends on the role/user of
the key, which isn't known by `KeyType` (`KeyType` is a tor-agnostic key
type such as `Ed25519Private`).
Signed-off-by: Gabriela Moldovan <gabi@torproject.org>
This renames `KeyIdentity` to `KeySpecifier` so it doesn't get confused
with the concept of an "identity key". `HsClientIdentity` is also
renamed for consistency.
Signed-off-by: Gabriela Moldovan <gabi@torproject.org>
We want each ID to have a unique form every time it is given out,
so that you can't use ID==ID to check whether Object==Object. (See
discussions leading to #848.)
We'd also like the form of object IDs to be a little annoying to
analyze, to discourage people from writing programs that depends on
their particular format. (We are reserving the right to change the
format whenever we want.)
We _don't_ want to use any cryptography here (yet), lest somebody
think that this is an actual security mechanism. (This isn't for
security; it's for encouraging developers to treat IDs as opaque.)
With that in mind, we now lightly obfuscate our generational indices
before returning them.
Per discussion referenced at #848, we want each operation that
returns a strong object ID to return a new, distinct strong ID.
Note that we no longer need to put strong and weak references in the
same arena; we can clean this code up a lot down the road.
Now we generate object IDs that we can parse. This is about to be
obsolete once we change how we generate objects and their IDs for #848,
but we may as well start from a working state.
This does the following:
- Gives every crate a `full`.
- Cause every `full` to depend on `full` from the lower-level
crates.
- Makes every feature listed _directly_ in `experimental` depend
on `__is_experimental`.
Nick Mathewson
gabi-250
Saksham Mittal