[tor-bugs] #11377 [BridgeDB]: New BridgeDB GimpCaptcha should be case insensitive (or should say it's sensitive)

Tor Bug Tracker & Wiki blackhole at torproject.org
Wed Apr 2 11:07:34 UTC 2014


#11377: New BridgeDB GimpCaptcha should be case insensitive (or should say it's
sensitive)
-------------------------+-------------------------------------------------
     Reporter:  wfn      |      Owner:  isis
         Type:  defect   |     Status:  needs_review
     Priority:  normal   |  Milestone:
    Component:           |    Version:
  BridgeDB               |   Keywords:  bridgedb-dist, bridgedb-https,
   Resolution:           |  easy, gimp-captcha
Actual Points:           |  Parent ID:
       Points:           |
-------------------------+-------------------------------------------------

Comment (by isis):

 Replying to [comment:3 wfn]:
 > Replying to [comment:2 isis]:
 > > I ''thought'' that most CAPTCHA system are case sensitive, but I could
 be wrong.
 >
 > Yeah, those captcha systems are not intuitive at all, right? fwiw, I'd
 have also guessed that most/many of them are case sensitive.
 >
 > > I'd accept a patch for either of the proposed fixes.
 >
 > Don't know if this helps, but in case it does: I'm linking to a commit
 (in a separate bug branch, `bug11377_gimpcaptcha`) (+ attaching its patch
 file) that makes the check be case insensitive (it's just one line / a few
 bytes. Doesn't break things.)
 >
 >
 https://github.com/wfn/bridgedb/commit/dd9e75ba234d2d4aad90aedb0bf163d8bb13811b
 >

 Awesome, thanks! I'll post my review in a separate comment.

 > I'm still learning to tame BridgeDB. Running all tests seem to take a
 long while. But I did run the
 `test_createChallenge_decryptedAnswerMatches()` from
 `bridgedb.test.test_captcha.GimpCaptchaTests`.
 >

 Most of the time spent during testing, as well as most of the time spent
 when "BridgeDB is down" (i.e. when I reply with "BridgeDB is single-
 threaded (#5232) and is parsing millions of descriptors"), is within the
 same `bridgedb.Stability.addOrUpdateBridgeHistory()` function (see
 #10724). This function is pretty brutal on CPU and memory, is blocking,
 and it needs to runs thousands and thousands of times. The algorithm
 within that function has a time complexity increasing
 [https://en.wikipedia.org/wiki/Time_complexity#Linearithmic_time
 linearithmically], relative to the number of bridges and timestamps
 already within the database.

 '''tl;dr''': I just merged sysrqb's patches for #5232 into the common
 `develop` branch, so all test runs and server startups/restarts should be
 ''significantly'' faster now.

 > If this goes well, I assume it'd be nice to create a separate test as
 well, something like
 `test_createChallenge_decryptedAnswerMatchesDifferentCases()` or so?

 Nope, thanks though! The `test_createChallenge_decryptedAnswerMatches`
 test will cover it.

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/11377#comment:4>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online


More information about the tor-bugs mailing list