dir auths leave out m line from vote when microdesc is over 1024 bytes

changed milestone to %Tor: 0.2.3.x-final

added component::core tor/tor milestone::Tor: 0.2.3.x-final priority::very high resolution::fixed status::closed tor-auth type::defect labels

#6491 (moved) was filed as the same bug.

Trac:
Priority: normal to major

This happens to be all the time, for the record.

For example, I have a line about zeller in my logs now. It seems that zeller has no m line in my cached-consensus-microdesc file.

Possibilities:

authorities are voting for microdescs badly. *authorities are forming consensuses badly.

Can we tell which?

moria1's vote for zeller is

r zeller /ug6gMCacQxUFfKKlljV1FnYtF0 7by41wV+3OqrV223t/taiy2leT4 2012-07-30 20:08:56 74.120.12.135 443 993
s Exit Fast Guard HSDir Named Running Stable V2Dir Valid
opt v Tor 0.2.3.19-rc
w Bandwidth=2715 Measured=5990
p accept 20-23,43,53,79-81,88,110,143,194,220,443,464-465,543-544,563,587,706,749,873,902-904,981,989-995,1194,1220,1293,1500,1723,1863,2082-2083,2086-2087,2095-2096,3128,3389,3690,4321,4643,5050,5190,5222-5223,5900,6666-6667,6679,6697,8000,8008,8080,8087-8088,8333,8443,8888,9418,9999-10000,19638

So it looks like my vote doesn't have an m line either.

Current theory is that zeller's microdesc is over 1k, with its big policy and big family line, so moria1 refuses to build it.

dirvote_create_microdescriptor(const routerinfo_t *ri)
{
  microdesc_t *result = NULL;
  char *key = NULL, *summary = NULL, *family = NULL;
  char buf[1024];

Then in dirserv_generate_networkstatus_vote_obj(), we do

      md = dirvote_create_microdescriptor(ri);
      if (md) {

Should we be more upset if !md?

Trac:
Summary: microdesc_list_missing_digest256(): Bug: Found an entry in networkstatus with no microdescriptor digest. to dir auths leave out m line from vote when microdesc is over 1024 bytes

Sec 3.6.2 of dir-spec.txt says

    "m" SP digest NL

        [Exactly once.]

Perhaps https://gitweb.torproject.org/tor.git/blob/HEAD:/src/or/routerparse.c#l2195 is the place to be more unhappy if !tok?

Trac:
Component: Tor Client to Tor Directory Authority

Thoughts:

We might want to raise the upper size limit on microdescriptors from 1K to 2K.
We ought to fix the voting algorithm so that routers with no microdesc get excluded from the microdesc consensus. Should probably have a new consensus method number for that.
The warning should indeed be at parse time.

Made the above changes in branch "bug6404" for inclusion in maint-0.2.3. Described the new consensus method in branch "bug6404_spec" in my public torspec repo. Please review?

Trac:
Status: new to needs_review

Trac:
Priority: major to critical

Not fixed in .20

Trac:
Username: funkstar

Right, it hasn't been merged, because nobody has reviewed it yet.

So you know, if the trac ticket isn't marked closed, and the changelog for a release doesn't say that the issue is fixed, then we don't think the issue is fixed either.

Uber quick review:

output, the retval of martlist_join_strings() in dirvote_create_microdescriptor() is not freed.
d3e1e45 obsoletes 2503cfa but it doesn't update its change/ file.

updated the branch; thanks!

Hm. Do the authorities still mostly track master? If so maybe I should split this into client side and auth side, and merge only the client side into 0.2.3.

If the authorities don't track master, then this needs to go into 0.2.3

Here are the dirauth versions:

Tonga		Tor 0.2.3.19-rc
dannenberg	Tor 0.2.3.19-rc
dizum		Tor 0.2.3.19-rc
gabelmoo		Tor 0.2.3.18-rc-dev
maatuska		Tor 0.2.3.15-alpha
moria1		Tor 0.2.4.0-alpha-dev
tor26		Tor 0.2.3.20-rc
turtles		Tor 0.2.3.20-rc
urras			Tor 0.2.3.19-rc

so, all but one are on 0.2.3

As for the spec, we should mention the size limit there and also explain how it is possible that no microdesc was agreed upon, because the impression I get from reading the spec is that no agreement is necessary since the microdesc is a strict transform of the generated consensus.

Section 3.5.1 is missing the addition of consensus method 13.

Otherwise, the spec changes seem fine

Oh, I see now, the size limit was an arbitrary limitation of the implementation, not meant to be specced. ok. Now that there isn't a limit we should make sure clients are OK with that, too. Or impose some limit to avoid a dos where we get forced to download a huge md?

I have a branch bug6404_spec to follow yours that cleans up a couple typos nearby.

I also can't find an explicit size limit when parsing microdescs as client, so I suppose that is ok as well.

ok, absent more commentary I'm merging this one into 0.2.3.

Trac:
Resolution: N/A to fixed
Status: needs_review to closed

Trac:
Keywords: N/A deleted, tor-auth added

Trac:
Component: Tor Directory Authority to Tor

closed

mentioned in issue #6491 (moved)

moved to tpo/core/tor#6404 (closed)

dir auths leave out m line from vote when microdesc is over 1024 bytes

Child items ...

Activity