Prop275: Eliminate "published" times from microdescriptor consensus
Proposal 275 will proposal will save a great deal of consensus and consensus-diff bandwidth down the road, with comparatively little effort. Let's get it implemented.
Activity
changed milestone to %Tor: unspecified
To review:
- In my public tor repository,
prop275_minimal_029, which permits published times to be in the future without breaking Tor. - In my public tor repository,
prop275_more_031, which stops all reliance on the published time in non-vote documents. - In my public torspec.git repository,
prop275_part1, where I update the specs to warn about the eventual behavior change.
For later:
* #21669 tracks the change where we eventually make the 'published' times uniform.- #21659 (moved) tracks the change where we eventually make the 'published' times uniform.
- In my public tor repository,
Replying to nickm:
To review:
- In my public tor repository,
prop275_minimal_029, which permits published times to be in the future without breaking Tor.
I thought we were only doing security backports to 0.2.9? Or does LTS buy us more latitude for change?
For later:
- #21669 tracks the change where we eventually make the 'published' times uniform.
The ticket #21669 doesn't exist yet.
- In my public tor repository,
-
Replying to teor:
Replying to nickm:
To review:
- In my public tor repository,
prop275_minimal_029, which permits published times to be in the future without breaking Tor.
I thought we were only doing security backports to 0.2.9? Or does LTS buy us more latitude for change?
I think that the LTS gives us a tiny bit more latitude, early in its LTS status, to do very-safe futureproofing. Of course, I'm making up the rules as I go along here---what do you think?
For later:
- #21669 tracks the change where we eventually make the 'published' times uniform.
The ticket #21669 doesn't exist yet.
Whoops, typo. Should have said "#21659 (moved)". Will edit.
- In my public tor repository,
Replying to nickm:
Replying to teor:
Replying to nickm:
To review:
- In my public tor repository,
prop275_minimal_029, which permits published times to be in the future without breaking Tor.
I thought we were only doing security backports to 0.2.9? Or does LTS buy us more latitude for change?
I think it's important, ok, and low risk, as long as the major distributions will take it. (Are any of them only taking security fixes for 0.2.9?)
- In my public tor repository,
-
I think it's important, ok, and low risk, as long as the major distributions will take it. (Are any of them only taking security fixes for 0.2.9?)
I think we've been judicious enough about backporting stuff that this shouldn't have too hard a time of getting in. And if it does, then they'll backport it later on, when their not-quite-Tor-029 series break in 2018/2019.
In
prop275_minimal_029, the changes file is confusing to me:+ [...] This change will + eventually allow us to stop listing meaningful "published" datesKind of weird that we want to stop doing something "meaningful" :)... maybe it was suppose to be "meaningless" or "useless" or "wrong" or ... ? If not, what does that mean exactly?
Trac:
Status: needs_review to needs_information-
lgtm; One quick comment:
In
routerstatus_format_entry(), this is used if not vote status is present:format_iso_time(published, rs->published_on_to_format);This matches the commit description which is that
published_on_to_formatis only used has an output for the control port. However, I think we should add a strong validation of that and possibly ator_assert(format == NS_CONTROL_PORT)in that if? If not, at least add a comment on how that is used for that function and what the caller should expect?Trac:
Status: needs_review to needs_revision 
Thoughts:
A) I think the patch in prop275_minimal_029 is safe and fine.
B) Check out in mark_my_descriptor_dirty_if_too_old() how we decide to republish our descriptor if our consensus entry says our descriptor is more than 18 hours old (#3327 (moved)):
else if (rs->published_on < slow_cutoff) retry_fast_reason = "version listed in consensus is quite old";So if we do the next step, which would be setting the timestamp to 2037 or whatever, we will disable this hack. Are we still using the hack much? I think we added it because we have a bunch of subtle bugs where relays forget to republish, or where relays do republish but the dir auths drop their newly published descriptor because it's too similar to the last one. I don't think we found or fixed those bugs.
At first I thought "hey, no problem, relays cache both flavors of consensus, because directory_caches_dir_info is so lenient." But then I realized that in the above code snippet, the rs is gotten from networkstatus_get_latest_consensus(), which will be the microdesc consensus. So I have resumed thinking that if we set published_on to always 2037, we will be disabling this hack. :(
-
Replying to arma:
So I have resumed thinking that if we set published_on to always 2037, we will be disabling this hack. :(
If we want to re-enable the hack (assuming that when we do the published_on change, we do it only in the microdescriptor consensus, and not in the vanilla consensus), here is code that would do that:
My
bug21642-hack1branch.