intrigeri:
> Hi,
>
> adrelanos wrote (12 May 2013 17:32:47 GMT) :
>> intrigeri:
>>> adrelanos wrote (06 May 2013 09:10:36 GMT) :
>>>> This means, it will wait a hardcoded 180 seconds in any case, even if
>>>> Tor is totally unable to connect (network down or censored). The
>>>> connection won't fail and curl won't exit before 180 seconds are over.
>>>
>>> I don't think we run htpdate in Tails before Tor is working. Do we?
>
>> No, but that's beside the point.
>
>> Just imagine Tor won't connect because there is no network or because
>> Tor is censored.
>
> IMHO, whether a proposed change fixes a real problem or an imaginary
> one is not beside the point.
It's not an imaginary problem. It's a real problem.
>> It's just that tails_htp (curl) would wait 180 seconds for every try.
>> And it can be quite a lot tries before tails_htp finally gives up.
>> Before that, there is no feedback whats happening.
>
> I acknowledge such a failure mode can happen outside of Tails, but
> this takes some special conditions, e.g.:
>
> * Tor censorship + a system that runs htpdate over Tor without
> checking whether Tor actually works (which our fork of htpdate is
> not designed to deal with)
No, that was not my concern.
> * a badly configured upstream router + a system that runs htpdate
> without checking whether the Internet is reachable (which our fork
> of htpdate is not designed to deal with)
As far I understand the tails_htp init script (in Tails), it does not
check if the Internet (Tor) is available or not.
> * some other cause I'm missing -- care to enlighten me?
I think you may assume, if Tor knows "I can't connect" or "I am not
fully connected yet", that it will send a reply on curl's SocksPort
"offline", curl recognizes and instantly stops. This is not the case.
Curl will wait the full 180 seconds. Every time.
So in comparison....
Current situation:
If Tor is censored - curl will instantly fail and tails_htp will inform
about it.
With --max-time 180:
If Tor is censored - curl will wait 180 seconds, try the next server
from the pool, wait again 180 seconds, repeat that another 10 times.
-----
If the new behavior is a non-issue in your opinion, I'll accept and stop
arguing about.
The --max-time switch alone imho doesn't make much sense. If it manages
to connect after 175 seconds and the transfer does not finish after 5
seconds, it will hit max-time and abort.
180 seconds for connecting including transfer is sane. But if there is
no connection established after 60 (or 120, or X) seconds, does it still
make sense to wait any longer? So I thought combining --max-time with
--connect-timeout is sane.
> Why not. I'm happy to reconsider this proposal once it comes with
a discussion about the added fingerprinting potential, balanced with
the importance of the real problems the proposed change fixes
I don't see any extra fingerprinting issues introduced by
--connect-timeout + --max-time, under the assumption, that --max-time
was accepted before already.
Cheers,
adrelanos
