(1)
On 5/7/19 2:16 AM, grarpamp wrote:
> ONION_CLIENT_AUTH_ADD
>
> is most clear... ONION (ok, what about onion),
> CLIENT (ok, what about client), AUTH (ok, and...)
> ADD (aha yes do that). And docs are self
> ordering into nice sections.
>
>
> ONION_CLIENT_ADD_AUTH
>
> doesn't follow because it
>
> Actually, we should have a simple format like "ed25519:" instead
> so then in 5 years, if we end up with 10 different authorization method, we
> can just pass "key:value" argument at will to the torrc option.
>
To be better, I prefer "ed25519:private:"
>>
>> Some more things to do:
>> - Re
On 05/14/2018 05:26 PM, George Kadianakis wrote:
> Suphanat Chunhapanya writes:
>
>> On 05/09/2018 03:50 PM, George Kadianakis wrote:
>>> I thought about this some more and discussed it with haxxpop on IRC. In
>>> the end, I think that perhaps starting with just
On 05/09/2018 03:50 PM, George Kadianakis wrote:
> I thought about this some more and discussed it with haxxpop on IRC. In
> the end, I think that perhaps starting with just desc auth and then in
> the future implementing intro auth is also an acceptable plan forward.
I think we have two more th
Hi,
On 04/28/2018 03:59 AM, meejah wrote:
> Then, if the service client has a problem later they have
> to remember NOT copy-paste the whole config when asking for
> help... sounds like lots to go wrong :) and I don't think this can be
> solved by tinkering with the names/layout of torrc options,
Hi,
On 04/28/2018 06:19 AM, teor wrote:
>> Or should we require the service to enable both for all clients?
>>
>> If you want to let the service be able to enable one while disable the
>> other, do you have any opinion on how to configure the torrc?
>
> If someone doesn't understand client auth i
As I am currently implementing the client authorization for onion
service v3 (https://github.com/torproject/tor/pull/36), I found some
problems in how we should let the users configure the client auth for
their services.
Before getting into the problem, I will explain how it works first.
--
Each
