Re: [tor-dev] sketch: An alternative prop224 authentication mechanism based on curve25519
George Kadianakis writes: > Nick Mathewson writes: > >> [ text/plain ] >> Hi! I thought I'd write this up while it was fresh in my mind. It >> could be used as an alternative method to the current proposed client >> authentication mechanism. We could implement both, or just this, or >> just the other. >> >> My description here will be a bit terser than we'd want in a proper >> proposal, but I wanted to share it. >> >> This design is based on George Kadianakis's client authentication >> design; it won't make sense unless you've read it. >> > > OK people, > > I have a more mature torspec branch now for your eyes and only. Please > see branch `prop224_client_auth_4` in my torspec repo: > > https://gitweb.torproject.org/user/asn/torspec.git/log/?h=prop224_client_auth_4 > > The changes are based on the feedback and discussion on this thread. > > The only real changes from `prop224_client_auth_3` is that it increases > the max descriptor size to 50k, and it removes the username/password > intro-level authorization. > > Please let me know of anything that seems off, or anything that can make > the proposal more readable. Otherwise, we should merge this upstream and > move forward with fixing the already merged prop224 HSDir code. > > Thanks! Hello, I merged the above patch to torspec.git. Thanks for the feedback and helpful comments everyone! ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] [PATCH] torspec: Keep proposal-status.txt up to date
s7r writes: > George Kadianakis wrote: >> Hello, >> >> I was in a train yesterday and decided to do some torspec >> housekeeping. So I updated the proposals/proposal-status.txt file which >> includes a summary of every proposal. >> >> You can find my changes here: >> >> https://gitweb.torproject.org/user/asn/torspec.git/commit/?h=proposal-status-update&id=45dd81c42f8d7f451947759d49f0e60f86ec9172 >> >> Please let me know if you see anything wrong with it. Otherwise, I will >> merge this to torspec soon since it's probably better than the status quo. >> >> Of course, there are still things we can do to make proposal-status.txt >> better, and also I bet some of the old proposals have changed status >> since they were written. I updated a few of them, but I didn't do all of >> them. >> >> Cheers! > > Lgtm. > > Only I don't see a status for: > 272 Listed routers should be Valid, Running, and treated as such > > (if this is intentional, pls ignore rest looks nice and clean) Thanks for that. Addressed in a followup commit. ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] [PATCH] torspec: Keep proposal-status.txt up to date
George Kadianakis wrote: > Hello, > > I was in a train yesterday and decided to do some torspec > housekeeping. So I updated the proposals/proposal-status.txt file which > includes a summary of every proposal. > > You can find my changes here: > > https://gitweb.torproject.org/user/asn/torspec.git/commit/?h=proposal-status-update&id=45dd81c42f8d7f451947759d49f0e60f86ec9172 > > Please let me know if you see anything wrong with it. Otherwise, I will > merge this to torspec soon since it's probably better than the status quo. > > Of course, there are still things we can do to make proposal-status.txt > better, and also I bet some of the old proposals have changed status > since they were written. I updated a few of them, but I didn't do all of > them. > > Cheers! Lgtm. Only I don't see a status for: 272 Listed routers should be Valid, Running, and treated as such (if this is intentional, pls ignore rest looks nice and clean) signature.asc Description: OpenPGP digital signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
[tor-dev] [PATCH] torspec: Keep proposal-status.txt up to date
Hello, I was in a train yesterday and decided to do some torspec housekeeping. So I updated the proposals/proposal-status.txt file which includes a summary of every proposal. You can find my changes here: https://gitweb.torproject.org/user/asn/torspec.git/commit/?h=proposal-status-update&id=45dd81c42f8d7f451947759d49f0e60f86ec9172 Please let me know if you see anything wrong with it. Otherwise, I will merge this to torspec soon since it's probably better than the status quo. Of course, there are still things we can do to make proposal-status.txt better, and also I bet some of the old proposals have changed status since they were written. I updated a few of them, but I didn't do all of them. Cheers! ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
[tor-dev] Is it safe for second_elapsed_callback() to be called less often?
Hi, When running hidden services on Android I've found it's necessary to hold a wake lock to keep the CPU awake. Otherwise Tor's second_elapsed_callback() doesn't get called once per second. When the CPU eventually wakes and the callback is called, if 100 seconds or more have passed since the last call, second_elapsed_callback() calls circuit_note_clock_jumped(), which marks any dirty circuits as unusable. If I understand right, this will have the effect of breaking any existing connections to the hidden service and making the service unreachable until it's built new intro circuits and published a new descriptor. #8239, #16387 and #19522 might help to reduce the downtime by improving our chances of reusing the same intro points, but we'd still lose the existing circuits. It would be nice if we could avoid this downtime without holding a permanent wake lock, which has a big impact on battery life. A possible workaround would be to use Android's alarm API to wake the controller process once per minute. The controller process can acquire a wake lock for a couple of seconds to allow second_elapsed_callback() to be called, then release the lock until the next alarm. However, it's pretty clear that Tor wants the callback to be called once per second and gets nervous if that doesn't happen, so I wanted to ask about the implications of calling the callback once or twice per minute before pursuing this idea further. Is it in any way sane? Another possibility would be to look into how Libevent's timers work. Perhaps we can ensure that the timers wake the CPU on Android, so second_elapsed_callback() and any other timer-based functions get called without keeping the CPU permanently awake? Thanks, Michael 0x9FC527CC.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
