Let's review these tickets at the next meeting using our 041-proposed process.
They're on the roadmap, so the review should focus on ticket size and team capacity (and sponsor expectations).
On going work of the entire prop289 implementation is in: ticket26288_041_01. It contains all the child ticket code since they all depend on each other.
I'm waiting on #29536 (moved) to be merged before submitting a PR. I've rebased the latest branch on #29536 (moved) so it can have a full integration: See ticket26288_041_02.
PR will arrive once everything is in master.
There will be one last thing to discuss: how to do this with protover. See the spec change that I propose to the proposal about this: ticket26288_01 (torspec).
So a piece missing is the integration with protover. I'm not entirely sure how to proceed code wise because what I've tried with SendMe=1 and it was not working. Basically, what I need is a confirmation that what is proposed makes sense and is doable that way. If so, I'll push the commit that implements this and will ask nickm to hunt down why it is failing.
Trac: Status: assigned to needs_review Reviewer: N/Ato ahf
So a piece missing is the integration with protover. I'm not entirely sure how to proceed code wise because what I've tried with SendMe=1 and it was not working. Basically, what I need is a confirmation that what is proposed makes sense and is doable that way. If so, I'll push the commit that implements this and will ask nickm to hunt down why it is failing.
SENDMEs are part of circuits and streams, so we could increment the Relay protocol version:
9.3. "Relay" The "relay" protocols are those used to handle CREATE/CREATE2 cells, and those that handle the various RELAY cell types received after a CREATE/CREATE2 cell. (Except, relay cells used to manage introduction and rendezvous points are managed with the "HSIntro" and "HSRend" protocols respectively.)
So a piece missing is the integration with protover. I'm not entirely sure how to proceed code wise because what I've tried with SendMe=1 and it was not working. Basically, what I need is a confirmation that what is proposed makes sense and is doable that way. If so, I'll push the commit that implements this and will ask nickm to hunt down why it is failing.
SENDMEs are part of circuits and streams, so we could increment the Relay protocol version:
Hmmmm the only reason I created a SendMe here is because it would have made Relay a bit messier... but I guess overall that is what we've designed Protover to support anyway.
Edit: After some discussions with Nick on IRC, problem with Relay is that we would need two new versions, that is "Auth. SENDME + tap" and "Auth. SENDME + ntor"... and that means using Relay implies a large matrix of versions every time we change a different cell type.
So the suggestion would be something like FlowCtrl=, have an implicit "1" that is current situation and add the value for 2 that would be for prop289.
We already have a SENDME version (0) that all tor supports. And now we want to support v1. In order for protover to "stop" the use of v0, we then need to introduce two new versions to Relay which right now would be 3 and 4.
Then to remove the usage of v0, we would advertise Relay=1-2,4 which should effectively exit() every client that does NOT support v1 that is Relay=4.
Currently there is a compilation failure on AppVeyor:
from ../src/core/or/or.h:32, from ../src/core/or/sendme.c:12:../src/core/or/sendme.c: In function 'sendme_connection_edge_consider_sending':../src/core/or/sendme.c:326:27: error: format '%lu' expects argument of type 'long unsigned int', but argument 5 has type 'size_t {aka unsigned int}' [-Werror=format=] log_debug(log_domain, "Outbuf %lu, queuing stream SENDME.", ^../src/lib/log/log.h:243:48: note: in definition of macro 'log_debug' log_fn_(LOG_DEBUG, domain, __FUNCTION__, args, ##__VA_ARGS__); \ ^~~~
Looks like the test failures on Travis isn't related to this code.
So a piece missing is the integration with protover. I'm not entirely sure how to proceed code wise because what I've tried with SendMe=1 and it was not working. Basically, what I need is a confirmation that what is proposed makes sense and is doable that way. If so, I'll push the commit that implements this and will ask nickm to hunt down why it is failing.
SENDMEs are part of circuits and streams, so we could increment the Relay protocol version:
Hmmmm the only reason I created a SendMe here is because it would have made Relay a bit messier... but I guess overall that is what we've designed Protover to support anyway.
Edit: After some discussions with Nick on IRC, problem with Relay is that we would need two new versions, that is "Auth. SENDME + tap" and "Auth. SENDME + ntor"... and that means using Relay implies a large matrix of versions every time we change a different cell type.
So the suggestion would be something like FlowCtrl=, have an implicit "1" that is current situation and add the value for 2 that would be for prop289.
You can do it this way: just like HSIntro etc.
We already have a SENDME version (0) that all tor supports. And now we want to support v1. In order for protover to "stop" the use of v0, we then need to introduce two new versions to Relay which right now would be 3 and 4.
Then to remove the usage of v0, we would advertise Relay=1-2,4 which should effectively exit() every client that does NOT support v1 that is Relay=4.
I think there's some confusion here.
The current Relay protocols are:
TAP and all the features in Tor 0.2.3 (including whatever flow control was in 0.2.3)