tor-commits October 2011

tor-commits@lists.torproject.org

18 participants
1256 discussions

[tor/maint-0.2.2] Free rend_data and intro_key when extra intro circs become general-purpose
by nickm＠torproject.org 20 Oct '11

20 Oct '11

commit 739c21e97b5c78ee76c7283993e7ca01f6d3beec Author: Robert Ransom <rransom.8774(a)gmail.com> Date: Tue Oct 18 07:08:02 2011 -0700 Free rend_data and intro_key when extra intro circs become general-purpose --- changes/bug4251 | 8 ++++++++ src/or/rendservice.c | 13 +++++++++++++ 2 files changed, 21 insertions(+), 0 deletions(-) diff --git a/changes/bug4251 b/changes/bug4251 new file mode 100644 index 0000000..303c9e6 --- /dev/null +++ b/changes/bug4251 @@ -0,0 +1,8 @@ + o Minor bugfixes: + + - When a hidden service turns an extra service-side introduction + circuit into a general-purpose circuit, free the rend_data and + intro_key fields first, so they won't be leaked if the circuit + is cannibalized for use as another service-side introduction + circuit. Bugfix on 0.2.1.7-alpha; fixes bug 4251. + diff --git a/src/or/rendservice.c b/src/or/rendservice.c index 6ed9650..0f57319 100644 --- a/src/or/rendservice.c +++ b/src/or/rendservice.c @@ -1421,7 +1421,20 @@ rend_service_intro_has_opened(origin_circuit_t *circuit) log_info(LD_CIRC|LD_REND, "We have just finished an introduction " "circuit, but we already have enough. Redefining purpose to " "general; leaving as internal."); + TO_CIRCUIT(circuit)->purpose = CIRCUIT_PURPOSE_C_GENERAL; + + { + rend_data_t *rend_data = circuit->rend_data; + circuit->rend_data = NULL; + rend_data_free(rend_data); + } + { + crypto_pk_env_t *intro_key = circuit->intro_key; + circuit->intro_key = NULL; + crypto_free_pk_env(intro_key); + } + circuit_has_opened(circuit); return; }

1 0

[tor/maint-0.2.2] Merge remote-tracking branch 'rransom-tor/bug4251-022' into maint-0.2.2
by nickm＠torproject.org 20 Oct '11

20 Oct '11

commit 3cb79a0286e3e4f87d590511f3cedb02e28de972 Merge: 5aa45ed 739c21e Author: Nick Mathewson <nickm(a)torproject.org> Date: Thu Oct 20 00:01:58 2011 -0400 Merge remote-tracking branch 'rransom-tor/bug4251-022' into maint-0.2.2 changes/bug4251 | 8 ++++++++ src/or/rendservice.c | 13 +++++++++++++ 2 files changed, 21 insertions(+), 0 deletions(-)

1 0

[tor/master] Fix crash when changing node restrictions with DNS lookup in progress
by nickm＠torproject.org 20 Oct '11

20 Oct '11

commit 5aa45ed6af87efaec5d6d4a32e8acbc733be8c3d Author: Nick Mathewson <nickm(a)torproject.org> Date: Wed Oct 19 23:14:05 2011 -0400 Fix crash when changing node restrictions with DNS lookup in progress Fixes bug 4259, bugfix on 0.2.2.25-alpha. Bugfix by "Tey'". Original message by submitter: Changing nodes restrictions using a controller while Tor is doing DNS resolution could makes Tor crashes (on WinXP at least). The problem can be repeated by trying to reach a non-existent domain using Tor: curl --socks4a 127.0.0.1:9050 inexistantdomain.ext .. and changing the ExitNodes parameter through the control port before Tor returns a DNS resolution error (of course, the following command won't work directly if the control port is password protected): echo SETCONF ExitNodes=TinyTurtle | nc -v 127.0.0.1 9051 Using a non-existent domain is needed to repeat the issue so that Tor takes a few seconds for resolving the domain (which allows us to change the configuration). Tor will crash while processing the configuration change. The bug is located in the addressmap_clear_excluded_trackexithosts method which iterates over the entries of the addresses map in order to check whether the changes made to the configuration will impact those entries. When a DNS resolving is in progress, the new_adress field of the associated entry will be set to NULL. The method doesn't expect this field to be NULL, hence the crash. --- changes/bug4259 | 4 ++++ src/or/connection_edge.c | 5 ++++- 2 files changed, 8 insertions(+), 1 deletions(-) diff --git a/changes/bug4259 b/changes/bug4259 new file mode 100644 index 0000000..bfccd3a --- /dev/null +++ b/changes/bug4259 @@ -0,0 +1,4 @@ + o Major bugfixes: + - Fix a crash bug when changing node restrictions while a DNS lookup + is in-progress. Fixes bug 4259; bugfix on 0.2.2.25-alpha. Bugfix + by "Tey'". diff --git a/src/or/connection_edge.c b/src/or/connection_edge.c index 6a69609..4763bf5 100644 --- a/src/or/connection_edge.c +++ b/src/or/connection_edge.c @@ -831,7 +831,10 @@ addressmap_clear_excluded_trackexithosts(or_options_t *options) char *nodename; routerinfo_t *ri; /* XXX023 Use node_t. */ - if (strcmpend(target, ".exit")) { + if (!target) { + /* DNS resolving in progress */ + continue; + } else if (strcmpend(target, ".exit")) { /* Not a .exit mapping */ continue; } else if (ent->source != ADDRMAPSRC_TRACKEXIT) {

1 0

[tor/master] Merge remote-tracking branch 'origin/maint-0.2.2'
by nickm＠torproject.org 20 Oct '11

20 Oct '11

commit 384e300cb4bc075f3b07e45017c9b5bcda050954 Merge: 0a083b0 5aa45ed Author: Nick Mathewson <nickm(a)torproject.org> Date: Wed Oct 19 23:16:08 2011 -0400 Merge remote-tracking branch 'origin/maint-0.2.2' changes/bug4259 | 4 ++++ src/or/connection_edge.c | 5 ++++- 2 files changed, 8 insertions(+), 1 deletions(-) diff --cc src/or/connection_edge.c index 508f69e,4763bf5..efaad79 --- a/src/or/connection_edge.c +++ b/src/or/connection_edge.c @@@ -942,9 -829,12 +942,12 @@@ addressmap_clear_excluded_trackexithost size_t len; const char *target = ent->new_address, *dot; char *nodename; - routerinfo_t *ri; /* XXX023 Use node_t. */ + const node_t *node; - if (strcmpend(target, ".exit")) { + if (!target) { + /* DNS resolving in progress */ + continue; + } else if (strcmpend(target, ".exit")) { /* Not a .exit mapping */ continue; } else if (ent->source != ADDRMAPSRC_TRACKEXIT) {

1 0

[tor/maint-0.2.2] Fix crash when changing node restrictions with DNS lookup in progress
by nickm＠torproject.org 20 Oct '11

20 Oct '11

1 0

[torspec/master] Update proposal index
by nickm＠torproject.org 20 Oct '11

20 Oct '11

commit e7f498d3a3ae3d2de918b5f479e2fbf087a1c229 Author: Nick Mathewson <nickm(a)torproject.org> Date: Wed Oct 19 20:05:23 2011 -0400 Update proposal index --- proposals/000-index.txt | 8 ++++++-- 1 files changed, 6 insertions(+), 2 deletions(-) diff --git a/proposals/000-index.txt b/proposals/000-index.txt index de31a92..7c54411 100644 --- a/proposals/000-index.txt +++ b/proposals/000-index.txt @@ -103,10 +103,12 @@ Proposals by number: 180 Pluggable transports for circumvention [OPEN] 181 Optimistic Data for Tor: Client Side [CLOSED] 182 Credit Bucket [DRAFT] -183 Refill Intervals [OPEN] +183 Refill Intervals [CLOSED] 184 Miscellaneous changes for a v3 Tor link protocol [OPEN] 185 Directory caches without DirPort [OPEN] 186 Multiple addresses for one OR or bridge [DRAFT] +187 Reserve a cell type to allow client authorization [OPEN] +188 Bridge Guards and other anti-enumeration defenses [OPEN] Proposals by status: @@ -137,9 +139,10 @@ Proposals by status: 177 Abstaining from votes on individual flags [for 0.2.3.x] 178 Require majority of authorities to vote for consensus parameters [for 0.2.3.x] 180 Pluggable transports for circumvention [for 0.2.3.x] - 183 Refill Intervals 184 Miscellaneous changes for a v3 Tor link protocol [for 0.2.3.x] 185 Directory caches without DirPort + 187 Reserve a cell type to allow client authorization [for 0.2.3.x] + 188 Bridge Guards and other anti-enumeration defenses ACCEPTED: 110 Avoiding infinite length circuits [for 0.2.3.x] [in 0.2.1.3-alpha] 117 IPv6 exits [for 0.2.3.x] @@ -193,6 +196,7 @@ Proposals by status: 171 Separate streams across circuits by connection metadata [in 0.2.3.3-alpha] 174 Optimistic Data for Tor: Server Side [in 0.2.3.1-alpha] 181 Optimistic Data for Tor: Client Side [in 0.2.3.3-alpha] + 183 Refill Intervals [in 0.2.3.5-alpha] SUPERSEDED: 112 Bring Back Pathlen Coin Weight 113 Simplifying directory authority administration

1 0

[torspec/master] proposal 183 was implemented in 0.2.3.5-alpha
by nickm＠torproject.org 20 Oct '11

20 Oct '11

commit 86bda8195e256aacd7c58b5d500c763edee909ce Author: Nick Mathewson <nickm(a)torproject.org> Date: Mon Oct 17 15:18:59 2011 -0400 proposal 183 was implemented in 0.2.3.5-alpha --- proposals/183-refillintervals.txt | 3 ++- 1 files changed, 2 insertions(+), 1 deletions(-) diff --git a/proposals/183-refillintervals.txt b/proposals/183-refillintervals.txt index c823d40..81ff5b0 100644 --- a/proposals/183-refillintervals.txt +++ b/proposals/183-refillintervals.txt @@ -2,7 +2,8 @@ Filename: 183-refillintervals.txt Title: Refill Intervals Author: Florian Tschorsch and Björn Scheuermann Created: 03-Dec-2010 -Status: Open +Status: Closed +Implemented-In: 0.2.3.5-alpha Overview:

1 0

[torspec/master] Proposal for Tor instances to accept other cell types before VERSIONS
by nickm＠torproject.org 20 Oct '11

20 Oct '11

commit cc2d3209079682ccc285a1e9a89caaf14be3fbe8 Author: Nick Mathewson <nickm(a)torproject.org> Date: Sun Oct 16 16:50:26 2011 -0400 Proposal for Tor instances to accept other cell types before VERSIONS --- proposals/187-allow-client-auth.txt | 131 +++++++++++++++++++++++++++++++++++ 1 files changed, 131 insertions(+), 0 deletions(-) diff --git a/proposals/187-allow-client-auth.txt b/proposals/187-allow-client-auth.txt new file mode 100644 index 0000000..3d3cf25 --- /dev/null +++ b/proposals/187-allow-client-auth.txt @@ -0,0 +1,131 @@ +Filename: 187-allow-client-auth.txt +Title: Reserve a cell type to allow client authorization +Author: Nick Mathewson +Created: 16-Oct-2011 +Status: Open +Target: 0.2.3.x + +Overview: + + Proposals 176 and 184 introduce a new "v3" handshake, coupled with + a new version 3 link protocol. This is a good time to introduce + other stuff we might need. + + One thing we might want is a scanning resistance feature for + bridges. This proposal suggests a change we should make right + away to enable us to deploy such a feature in future versions of + Tor. + +Motivation: + + If an adversary has a suspected bridge address/port combination, + the easiest way for them to confirm or disconfirm their suspicion + is to connect to the address and see whether they can do a Tor + handshake. The easiest way to fix this problem seems to be to + give out bridge addresses along with some secret that clients + should know, but which an adversary shouldn't be able to learn + easily. The client should prove to the bridge that it's + authorized to know about the bridge, before the bridge acts like a + bridge. If the client doesn't show knowledge of the proper + secret, the bridge should at like an HTTPS server or a bittorrent + tracker or something. + + This proposal *does not* specify a way for clients to authorize + themselves at bridges; rather, it specifies changes that we should + make now in order to allow this kind of authorization in the + future. + +Design: + + Currently, now that proposal 176 is implemented, if a server + provides a certificate that indicates a v3 handshake, and the + client understands how to do a V3 handshake, we specify that the + client's first cell must be a VERSIONS cell. + + Instead, we make the following specification changes: + + We reserve a new variable-length cell type, "AUTHORIZE." + + We specify that any number of PADDING or VPADDING or AUTHORIZE + cells may be sent by the client before it sends a VERSIONS cell. + Servers that do not require client authorization MUST ignore such + cells, except to include them when calculating the HMAC that will + appear in the CLOG part of a client's AUTHENTICATE cell. + + We still specify that clients SHOULD send VERSIONS as their first + cell; only in some future version of Tor will an AUTHORIZE cell be sent + first. + +Discussion: + + This change allows future versions of the Tor client to know that + some bridges need authorization, and to send them authentication + before sending them anything recognizably Tor-like. + + The authorization cell needs to be received before the server can + send any Tor cells, so we can't just patch it in after the + VERSIONS cell exchange: the server's VERSIONS cell is unsendable + until after the AUTHORIZE has been accepted. + + Note that to avoid scanning attacks, it's not sufficient to wait + for a single cell, and then either handle it as authorization or + reject the connection. Instead, we need to decide what kind of + server we're impersonating, and respond once the client has + provided *either* an authorization cell, *or* a recognizably valid + or invalid command in the impersonated protocol. + + +Alternative design: Just use pluggable transports + + Pluggable transports can do this too, but in general, we want to + avoid designing the Tor protocol so that any particular desirable + feature can only be done with a pluggable transport. That is, any + feature that *every* bridge should want, should be doable in Tor + proper. + + Also, as of 16 Oct 2011, pluggable transports aren't in general + use. Past experience IMO suggests that we shouldn't offload + architectural responsibilities to our chickens until they've + hatched. + +Alternative design: Out-of-TLS authorization + + There are features (like port-knocking) designed to allow a client + to show that it's authorized to use a bridge before the TLS + handshake even happens. These are appropriate for bunches of + applications, but they're trickier with an adversary who is + MITMing the client. + +Alternative design: Just use padding. + + Arguably, we could only add the "VPADDING" cell type to the list + of those allowed before VERSIONS cells, and say that any client + authorization we specify later on will be sent as a VPADDING + cell. But that design is kludgy: padding should be padding, not + semantically significant. Besides, cell types are still fairly + plentiful. + +Counterargument: specify it later + + We could, later on, say that if a client learns that a bridge + needs authorization, it should send an AUTHORIZE cell. So long as + a client never sends an AUTHORIZE to anything other than a bridge that + needs authorization, it'll never violate the spec. + + But all things considered, it seems easier (just a few lines of + spec and code) to let bridges eat unexpected authorization now + than it does to have stuff fail later when clients think that a + bridge needs authorization but it doesn't. + +Counterargument: it's too late! + + We've already got the prop176 branch merged and running on a few + servers. But as of this writing, it isn't in any Tor version. + + Even if it *is* out in an alpha before we can get this proposal + accepted and implemented, that's not a big disaster. In the worst + case, where future clients don't know whom to send authorization + to so they need to send it to _all_ v3 servers, they will at worst + break their connections only to a couple of alpha versions which + one hopes by then will be long-deprecated already. +

1 0

[torspec/master] Proposal for bridges to redirect traffic through guard nodes
by nickm＠torproject.org 20 Oct '11

20 Oct '11

commit 1e20a8fac4d9ede8961c6fc920e73d3f96e2e889 Author: Nick Mathewson <nickm(a)torproject.org> Date: Sun Oct 16 16:49:42 2011 -0400 Proposal for bridges to redirect traffic through guard nodes --- proposals/188-bridge-guards.txt | 213 +++++++++++++++++++++++++++++++++++++++ 1 files changed, 213 insertions(+), 0 deletions(-) diff --git a/proposals/188-bridge-guards.txt b/proposals/188-bridge-guards.txt new file mode 100644 index 0000000..249d794 --- /dev/null +++ b/proposals/188-bridge-guards.txt @@ -0,0 +1,213 @@ +Filename: 188-bridge-guards.txt +Title: Bridge Guards and other anti-enumeration defenses +Author: Nick Mathewson +Created: 14 Oct 2011 +Status: Open + +1. Overview + + Bridges are useful against censors only so long as the adversary + cannot easily enumerate their addresses. I propose a design to make + it harder for an adversary who controls or observes only a few + nodes to enumerate a large number of bridges. + + Briefly: bridges should choose guard nodes, and use the Tor + protocol's "Loose source routing" feature to re-route all extend + requests from clients through an additional layer of guard nodes + chosen by the bridge. This way, only a bridge's guard nodes can + tell that it is a bridge, and the attacker needs to run many more + nodes in order to enumerate a large number of bridges. + + I also discuss other ways to avoid enumeration, recommending some. + + These ideas are due to a discussion at the 2011 Tor Developers' + Meeting in Waterloo, Ontario. Practically none of the ideas here + are mine; I'm just writing up what I remember. + +2. History and Motivation + + Under the current bridge design, an attacker who runs a node can + identify bridges by seeing which "clients" make a large number of + connections to it, or which "clients" make connections to it in the + same way clients do. This has been a known attack since early + versions {XXXX check} of the design document; let's try to fix it. + +2.1. Related ideas: Guard nodes + + The idea of guard nodes isn't new: since 0.1.1, Tor has used guard + nodes (first designed as "Helper" nodes by Wright et al in {XXXX}) + to make it harder for an adversary who controls a smaller number of + nodes to eavesdrop on clients. The rationale was: an adversary who + controls or observes only one entry and one exit will have a low + probability of correlating any single circuit, but over time, if + clients choose a random entry and exit for each circuit, such an + adversary will eventually see some circuits from each client with a + probability of 1, thereby building a statistical profile of the + client's activities. Therefore, let each client choose its entry + node only from among a small number of client-selected "guard" + nodes: the client is still correlated with the same probability as + before, but now the client has a nonzero chance of remaining + unprofiled. + +2.2. Related idea: Loose source routing + + Since the earliest versions of Onion Routing, the protocol has + provided "loose source routing". In strict source routing, the + source of a message chooses every hop on the message's path. But + in loose source routing, the message traverses the selected nodes, + but may also traverse other nodes as well. In other words, the + client selects nodes N_a, N_b, and N_c, but the message may in fact + traverse any sequence of nodes N_1...N_j, so long as N_1=N_a, + N_x=N_b, and N_y=N_c, for 1 < x < y. + + Tor has retained this feature, but has not yet made use of it. + +3. Design + + Every bridge currently chooses a set of guard nodes for its + circuits. Bridges should also re-route client circuits through + these circuits. + + Specifically, when a bridge receives a request from a client to + extend a circuit, it should first create a circuit to its guard, + and then relay that extend cell through the guard. The bridge + should add an additional layer of encryption to outgoing cells on + that circuit corresponding to the encryption that the guard will + remove, and remove a layer of encryption on incoming cells on that + circuit corresponding to the encryption that the guard will add. + +3.1. An example + + This example doesn't add anything to the design above, but has some + interesting inline notes. + + - Alice has connected to her bridge Bob, and built a circuit + through Bob, with the negotiated forward and reverse keys KB_f + and KB_r. + + - Alice then wants to extend the circuit to node Charlie. She + makes a hybrid-encrypted onionskin, encrypted to Charlie's + public key, containing her chosen g^x value. She puts this in + an extend cell: "Extend (Charlie's address) (Charlie's OR + Port) (Onionskin) (Charlie's ID)". She encrypts this with + KB_f and sends it as a RELAY_EARLY cell to Bob. + + - Bob receives the RELAY_EARLY cell, and decrypts it with KB_f. + He then sees that it's an extend cell for him. + + So far, this is exactly the same as the current procedure that + Alice and Bob would follow. Now we diverge: + + - Instead of connecting to Charlie directly, Bob makes sure that + he is connected to his guard, Guillaume. Bob uses a + CREATE_FAST cell (or a CREATE cell, but see 4.1 below) to open a + circuit to Guillaume. Now Bob and Guillaume share keys KG_f + and KG_b. + + - Now Bob encrypts the Extend cell body with KG_f and sends it + as a RELAY_EARLY cell to Guillaume. + + - Guillaume receives it, decrypts it with KG_f, and sees: + "Extend (Charlie's address) (Charlie's OR Port) (Onionskin) + (Charlie's ID)". Guillaume acts accordingly: creating a + connection to Charlie if he doesn't have one, ensuring that + the ID is as expected, and then sending the onionskin in a + create cell on that connection. + + Note that Guillaume is behaving exactly as a regular node + would upon receiving an Extend cell. + + - Now the handshake finishes. Charlie receives the onionskin + and sends Guillaume "CREATED g^y,KH". Guillaume sends Bob + "E(KG_r, EXTENDED g^y KH)". (Charlie and Guillaume are still + running as regular Tor nodes do today). + + - With this extend cell, and with all future relay cells + received on this circuit, Bob first decrypts the cell with + KG_r, then re-encrypts it with KB_r, then passes it to Alice. + When Alice receives the cell, it will be just as she would + have received if Bob had extended to Charlie directly. + + - With all future outgoing cells that he receives from Alice, + Bob first decrypts the cell with KA_f, and if the cell does + not have Bob as its destination, Bob encrypts it with KG_f + before passing it to Guillaume. + + Note that this design does not require that our stream cipher + operations be transitive, even though they are. + + Note also that this design requires no change in behavior from any + node other than Bob the bridge. + + Finally, observe that even though the circuit is one hop longer + than it would be otherwise, no relay's count of permissible + RELAY_EARLY cells falls lower than it otherwise would. This is + because the extra hop that Bob adds is done with a CREATE_FAST + cell, and so he does not need to send any RELAY_EARLY cells not + originated by Alice. + +4. Other ideas and alternative designs + + In addition to the design above, there are more ways to try to + prevent enumeration. + +4.1. Make it harder to tell clients from bridges + + Right now, there are multiple ways for the node after a bridge to + distinguish a circuit extended through the bridge from one + originating at the bridge. (This lets the node after the bridge + tell that a bridge is talking to it.) + + One of the giveaways here is that the first hop in a circuit is + created with CREATE_FAST cells, but all subsequent hops are created + with CREATE cells. In the above design, it's no longer quite so + simple to tell, since all of the circuits that extend through a + bridge now reach its guards through CREATE_FAST cells, whether the + bridge originated them or not. + + (If we adopt a faster circuit extension algorithm -- for example, + Goldberg, Stebila, and Ustaoglu's design instantiated over + curve25519 -- we could also solve this issue by eliminating + CREATE_FAST/CREATED_FAST entirely, which would also help our + security margin a little.) + + The CREATE/CREATE_FAST distinction is not the only way for a + bridge's guard to tell bridges from orginary clients, however. + Most importantly, a busy bridge will open far more circuits than a + client would. More subtly, the timing on response from the client + will be higher and more highly variable that it would be with an + ordinary client. I don't think we can make bridges behave wholly + indistinguishably from clients: that's why we should go with guard + nodes for bridges. + +4.2. Client-enforced bridge guards + + What if Tor didn't have loose source routing? We could have + bridges tell clients what guards to use by advertising those guard + in their descriptors, and then refusing to extend circuits to any + other nodes. This change would require all clients to upgrade in + order to be able to use the newer bridges, and would quite possibly + cause a fair amount of pain along the way. + + Fortunately, we don't need to go down this path. So let's not! + +4.3. Separate bridge-guards and client-guards + + In the design above, I specify that bridges should use the same + guard nodes for extending client circuits as they use for their own + circuits. It's not immediately clear whether this is a good idea + or not. Having separate sets would seem to make the two kinds of + circuits more easily distinguishable (even though we already assume + they are distinguishable). Having different sets of guards would + also seem like a way to keep the nodes who guard our own traffic + from learning that we're a bridge... but another set of nodes will + learn that anyway, so it's not clear what we'd gain. + +5. Other considerations + + What fraction of our traffic is bridge traffic? Will this alter + our circuit selection weights? + + Are the current guard selection/evaluation/replacement mechanisms + adequate for bridge guards, or do bridges need to get more + sophisticated?

1 0

[pytorctl/master] Bug #4097: Clear old last_exit before requesting a new one
by mikeperry＠torproject.org 19 Oct '11

19 Oct '11

commit e15ed99df8e8e04cadd0f3792e42a621df6fbe02 Author: Mike Perry <mikeperry-git(a)fscked.org> Date: Wed Oct 19 16:32:34 2011 -0700 Bug #4097: Clear old last_exit before requesting a new one Should eliminate the keyerror in the test's node_map, which seemed to be due to really stale last_exits laying around from previous tests on a different consensus. --- ScanSupport.py | 2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/ScanSupport.py b/ScanSupport.py index 8985fd7..e6752c5 100644 --- a/ScanSupport.py +++ b/ScanSupport.py @@ -164,6 +164,8 @@ class ScanHandler(PathSupport.PathBuilder): def notlambda(sm): plog("DEBUG", "Job for setexit: "+exit_name) cond.acquire() + # Clear last successful exit, we're running a new test + self.last_exit = None sm.set_exit(exit_name) cond.notify() cond.release()

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

tor-commits October 2011