conf_changed can happen before bootstrap

[meejah]

While its still reading the config, it looks like TorConfig can get CONF_CHANGED events (and probably does bad things). It should ignore CONF_CHANGED until after bootstrap is completed.

See TheTorProject/bwscanner@ccddac6#diff-5d97531ed54d2f8c4d91ebce0fb91774R170

[meejah]

Hmm, how would that happen? I guess if you created two TorConfig objects connected to the same protocol "at the same time", and called .save() on one while the other was still bootstrapping..?

[meejah]

But also hmm: I don't think anything bad happens if we get a CONF_CHANGED while bootstrapping (or at least i can't make a unit-test do any bad stuff)

[juga0]

I'm not sure what you mean. I see 3 cases:

1. There're options that can not be changed on a running tor instance, but i don't recall now the error (if any) they give.
2. In the code previously linked, i think it happened what you mention, since tor.config is not an attribute of Tor and it was getting assigned a new TorConfig object
3. As a different question (maybe new issue), which is the recommended way to change the configuration when connecting to tor?. I've try to updated the config in TheTorProject/bwscanner@b9ad1a5#diff-5d97531ed54d2f8c4d91ebce0fb91774R77 and now i actually got CONF_CHANGED https://travis-ci.org/TheTorProject/bwscanner/jobs/357532664 :)

[meejah]

@juga0 that way (in the linked code) looks good to me -- but that CONF_CHANGED thing is interesting! I guess it's somehow getting a 650 event while still reading the consensus?!

[meejah]

Could be a bug in .get_config returning too soon...?