17:58:38 <mikeperry> #startmeeting tbb-dev
17:58:38 <MeetBot> Meeting started Mon Sep  8 17:58:38 2014 UTC.  The chair is mikeperry. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:58:38 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
17:58:56 <Sebastian> meetbot's clock is wrong, too :)
17:59:19 <mikeperry> ok, let's get started
17:59:50 <Yawning> *lurks incase pt stuff comes up*
18:00:02 <mikeperry> last week I wrote the status report, reorganized all of the tickets for september+FF31esr, and reviewed most of the FF31 networking code
18:00:36 <mikeperry> this week, I'll mostly be at the OTF summit, but hopefully will get a chance to finish up the networking code review
18:00:59 <mikeperry> and write a couple patches for defense-in-depth
18:01:54 <mikeperry> oh, I also hunted down some copies of the OSX10.7 SDK
18:02:01 <mikeperry> #12761
18:02:08 <mikeperry> that's it for me
18:04:12 <mikeperry> who wants to go next?
18:04:25 <gacar> i (gunes) can give a one line summary
18:04:46 <GeKo> I go after Günes
18:04:53 <mikeperry> ok
18:05:07 <gacar> worked on fingerprinting related issues, mostly webworker issue
18:05:32 <gacar> will be working on fingerprinting test suite aka panopticlick site
18:06:12 <gacar> for the web #13027 i suggest we wait for mozilla guys. that's all from me
18:06:27 <gacar> s/web/webworker/
18:06:48 <GeKo> I did mainly work on getting the ESR 31 to build in our gitian environment.
18:07:00 <GeKo> on Linux we are in good shape now, I think
18:07:35 <GeKo> I got reproducible tor browser gbuilt.zip and debug.zip files on different machines
18:08:04 <GeKo> for Mac OS I think I am done as well but I currently can't test it due to the rsync hang
18:08:27 <GeKo> this is quite mysterious as it is currently happening reliable on three different machines both with LXC and KVM
18:08:50 <mikeperry> is that the usual intermittent hang for osx?
18:08:55 <mikeperry> is it worse on ff31 now?
18:08:58 <GeKo> Windows is failing in the packaging step, so wea re close, too.
18:09:25 <GeKo> yes, and it seems to be worse but on the other hand I can't build veen build ESR 24 atm
18:09:31 <GeKo> *even
18:09:32 <Yawning> (I failed to build alpha2 because of that osx thing, not sure if I should retry)
18:09:51 <GeKo> I have no clue what is happening on my machines. I need to look a bit depper
18:10:07 <GeKo> or cross my fingers
18:10:28 <GeKo> anyway, I found two updater related bugs
18:10:46 <GeKo> and I reviwed some code and prepared a Torbutton patch we need for ESR 31
18:10:51 <GeKo> *rviwed
18:11:07 <GeKo> damn, *reviewed
18:11:16 <GeKo> this week:
18:11:34 <GeKo> if we are lucky I get the ESR building on all OSes in proper shape
18:12:13 <GeKo> then 'll look at other patches to rebae and write and plan to do some code review where needed.
18:12:19 <GeKo> *rebase
18:12:51 <mikeperry> what were the updater bugs? I saw #13049
18:12:58 <GeKo> oh btw some numbers the ESR based packages are more than 33% larger than thes ESR 24 based one
18:13:10 <GeKo> (that is on linux)
18:13:14 <mikeperry> wow
18:13:22 <GeKo> #13087
18:13:31 <GeKo> and
18:13:43 <GeKo> #13047
18:14:01 <GeKo> tha't it for me
18:14:07 * GeKo can't type today
18:15:37 <Yawning> (so for this osx thing, should I just assume at some later date rebasing will let me build again?)
18:15:43 <mikeperry> gacar: I am wondering about the webworker bug.. if webworkers are returning true for IsCallerChrome, that could be a serious security issue..
18:15:49 <GeKo> Yawning: maybe :)
18:16:06 <GeKo> honestly, yes.
18:16:18 <Yawning> I don't think I actually need to build snapshots for a while (next step is bridge deployment and bugging someone to maybe merge the branch)
18:16:19 <GeKo> we need that somehow fixed for the regular release building
18:16:47 <Yawning> Since I belive everything is good to go, with "just add bridges" at this point
18:17:11 <gacar> mikeperry: possibly, you mean more serious than fingerprinting, right?
18:17:26 <GeKo> yes
18:18:14 <mikeperry> gacar: yeah, that check usually is used to see if things can access priviledged XPCOM functions
18:18:16 <GeKo> I wonder why they implemented it that way
18:19:39 <GeKo> gacar: You linked to the ESr 24 source in trac but the issue is still on in ESR 31, right?
18:19:45 <mikeperry> it's nsContentUtils::IsCallerChrome() that it's calling?
18:19:46 <GeKo> *one
18:20:14 <gacar> yes to both geko and mikeperry
18:21:06 <gacar> i built a esr24 version returning stupid values for iscallerchrome branch
18:21:27 <gacar> and observed these values from the workers.
18:21:41 <gacar> i.e. made sure that iscallerchrome returns true
18:21:58 <MarkSmith> Maybe that is something Mozilla is willing to fix?  Seems bad.
18:22:36 <gacar> for the fingerprinting related: we can fix the navigator props
18:22:51 <gacar> but more serious stuff like xpcom acces i dont' know
18:22:59 <gacar> disable webworkers?
18:23:50 <mikeperry> can you access COmponents.interfaces and Components.classes in a vanilla Firefox from WebWorkers?
18:24:38 <gacar> me don't know. should they be part of global window object?
18:24:43 <gacar> if yes then no, no access.
18:25:29 <mikeperry> hrmm.. then an exploit might need to get more creative
18:25:42 <mikeperry> .wrappedJSObject on something might do it
18:26:27 <gacar> no wrappedjsobject: all window properties here #13044
18:27:08 <gacar> it seems since workers are not thread safe they had to make special I/F for accessing prefs
18:30:34 <gacar> i mean everything is pretty limited, but they try to extend it (canvas etc.).
18:30:49 <gacar> good to keep an eye on...
18:30:55 <mikeperry> ok, I suppose I can ping some mozilla people
18:32:00 <mikeperry> we should get back on track. who wants to go next?
18:32:23 * MarkSmith can go
18:32:47 <MarkSmith> Last week, Kathy Brade and I rebased the updater patches for ESR31.  Arthur merged them into his patch branch
18:32:53 <MarkSmith> We also did some testing of TB 4.0a2's updater and found (and fixed) #13049
18:33:08 <MarkSmith> We provided some info for #13005 and did miscellaneous things such as testing Tom Ritter's 64-bit Mac OS build.
18:33:19 <MarkSmith> Today, we looked at #13087.  We need someone to place a couple of files on www.torproject.org in order to make that problem disappear.
18:33:32 <MarkSmith> We should do that ASAP in my opnion.
18:33:39 <MarkSmith> This week, we plan to work on other ESR31 patches, specifically canvas and DOM storage and
18:33:45 <MarkSmith> hopefully we will have time to work on #13047 (Updater should not send Kernel and GTK version).
18:33:54 <MarkSmith> That's all for now.
18:34:30 <GeKo> MarkSmith: I am for "Tor Browser", too
18:34:41 <mikeperry> does arthuredelstein have a version of #13049 for ff31?
18:35:15 <arthuredelstein> checking...
18:35:30 <MarkSmith> mikeperry: yes, we found out about #13049 and fixed it before sending him the ESR31 patch… so the fix was included in what he has.
18:36:14 <arthuredelstein> Oh good :0
18:36:22 <MarkSmith> I guess there is another thing we could talk about:  "TorBrowser" vs. "Tor Browser" for the app display name
18:36:41 <MarkSmith> (thanks for the reminder GeKo)
18:37:38 <GeKo> we currently use "Tor Browser" all over the place it seems...
18:38:10 <GeKo> (on about:tor) and on the titlebar at least
18:38:10 <mikeperry> yeah, "Tor Browser"
18:38:28 <MarkSmith> I am not sure will break if we put a space in MOZ_APP_DISPLAY_NAME...
18:38:34 <MarkSmith> Hopefully nothing.
18:39:25 <GeKo> yeah, what could possibly go wrong :)
18:39:28 <Yawning> (For my reference for when I have bridge pacakges, how many default bridges should there be for obfs4?)
18:40:02 <MarkSmith> Sorry; the correct variable is MOZ_APP_DISPLAYNAME (only two underscores)
18:40:36 <Yawning> (and beyond having a somewhat tested tor-browser-bundle branch, is there more stuff I need to do from the TBB people's perspective?)
18:40:36 <MarkSmith> I will open a separate ticket for the "Tor Browser" issue.
18:43:44 <GeKo> Yawning: 3-5 bridges maybe?
18:44:51 <mikeperry> MarkSmith: does https://www.torproject.org/dist/torbrowser/update/ look correct for #13087?
18:46:21 <MarkSmith> mikeperry: I'll let you know in a minute.
18:46:25 <mikeperry> in the meantime, who wants to go next?
18:46:33 * arthuredelstein can go next
18:46:38 <boklm> the result of this url looks good: https://www.torproject.org/dist/torbrowser/update/alpha/Darwin_x86-gcc3/1/4.0-alpha-2/fr
18:46:51 <arthuredelstein> Last week I wrote a patch for #10822 and also submitted it to Mozilla. I also did naive rebases of patches to ESR31 for #12523, #11955, and #13033, but though these compile, they unfortunately all appear to be nonfunctional and need more careful debugging. And I worked on a patch for #13019. This week I hope to keep working on these patches and maybe write some more regression tests for 12620.
18:47:31 <Yawning> (GeKo: mmk, I know of 2 bridges, one being mine that I'm not sure if I'll keep running, I'll get more Soon)
18:48:16 <arthuredelstein> that's it for me
18:48:19 <GeKo> arthuredelstein: you can take out the integer overflow related patch
18:48:24 <GeKo> both issues are fixed in esr 31
18:49:25 <MarkSmith> mikeperry: https://www.torproject.org/dist/torbrowser/update/ looks correct to me.  Thanks!
18:51:11 <arthuredelstein> GeKo: Which one do you have in mind?
18:51:20 <arthuredelstein> I think maybe I've already taken it out
18:51:30 <GeKo> let me see
18:52:19 <arthuredelstein> Current list is at https://github.com/arthuredelstein/tor-browser/commits/12620
18:52:56 <GeKo> https://github.com/arthuredelstein/tor-browser/commit/41d164fe874ef7f850dccb92ba87717ebd0ebe7c
18:53:23 <GeKo> it is still there it seems
18:53:41 <arthuredelstein> That seems to be a very minor fixup that may or may not be useful
18:55:41 <arthuredelstein> I already didn't apply the main patch because of your comment: https://trac.torproject.org/projects/tor/ticket/12620#comment:26
18:55:53 <GeKo> ok
18:55:57 <arthuredelstein> But probably we can drop this fixup as well as I believe it compiles anyway
18:56:21 <GeKo> yes, if it compiles then just drop it
18:56:28 <GeKo> one patch less to maintain
18:56:31 <mikeperry> oh, the namespace fix was just for ff24, yes
18:56:39 <arthuredelstein> OK
18:57:24 <arthuredelstein> I'll revert it
18:59:18 <mikeperry> ok, who's next?
18:59:18 * boklm can go next
19:00:06 <boklm> Last week I added the test that was suggested by iSEC to enumerate DOM objects, as a mozmill test: https://gitweb.torproject.org/boklm/tor-browser-bundle-testsuite.git/blob/HEAD:/mozmill-tests/tbb-tests/dom-objects-enumeration.js
19:00:28 <boklm> it includes the list of objects we have in the current version, and should make an error if there are new ones
19:01:06 <boklm> I launched a rebuild of our patches on the tor-browser-24.8.0esr-3.x-1 branch to run the mochitest tests (still running): http://93.95.228.164/reports/index-browserunit-tor-browser-24.8.0esr-3.x-1.html
19:01:18 <boklm> but it seems we have a lot of tests randomly failing because of "Test timed out", so I'm planning to make them run 3 or 4 times and only make them failed if they always fail
19:01:48 <mikeperry> possibly the JIT options making them slower than expected?
19:02:03 <boklm> hmm, maybe
19:02:55 <arthuredelstein> I think it might be nice to have the mozmill test in tor-browser.git, since we expect a different object list for ESR24 and ESR31.
19:03:56 <GeKo> well, Mozilla does not keep their mozmill tests in the offical repo, IIRC
19:03:58 <mikeperry> yeah, this test is to help us find new DOM pobjects we may have otherwised missed
19:04:25 <GeKo> so, I wonder whether we should do it or should put the tests in an own repo...
19:04:33 <arthuredelstein> I could be ported to a mochitest
19:04:43 <arthuredelstein> *It
19:04:59 <boklm> hmm, maybe it could be done as a mochitest yes
19:05:10 <mikeperry> we should probably try to recurse on all of those objects, too, so we can produce a diff of new properties between esr24 and esr31?
19:05:12 <GeKo> yes, probably. and then it would just be another patch, right
19:05:44 <boklm> yes
19:06:33 <arthuredelstein> I have a recursive version which I can post in a sec
19:06:40 <arthuredelstein> At least the beginnings of one
19:07:32 <arthuredelstein> https://github.com/arthuredelstein/fingerprint
19:08:42 <boklm> nice
19:10:29 <boklm> I also modified the update response script for the issue reported in #13087, so that it does not return an update when we are running the latest version
19:10:52 <boklm> This week I'm planning to remove the mochitest "Test timed out" errors
19:11:06 <boklm> Try the updater with updates generated by the updates response script, and start writting some instructions about how to use it during the release process
19:11:36 <boklm> And look at #13020 for some testing with mbox
19:11:53 <boklm> that's it for me
19:11:57 <Sebastian> nickm: are you still around?
19:13:15 <mikeperry> ok
19:15:12 <mikeperry> anyone else?
19:15:20 <mttp> Hey folks
19:15:26 <GeKo> hi!
19:16:17 <mttp> Someone got the following werror message when getting a new identity:
19:16:18 <mttp> Torbutton: Error clearing NoScript Temporary Permissions: TypeError: Components.classes['@maone.net/noscript-service;1'] is undefined
19:16:52 <GeKo> yes, this is known; she/he is not expected to have NoScript disabled
19:16:53 <mikeperry> did they somehow disable/uninstall noscript?
19:17:21 <mttp> They made no mention of having uninstalled or reintalled it
19:17:31 <mttp> Is there a ticket?
19:17:39 <GeKo> yes
19:17:43 <GeKo> let me see
19:18:27 <GeKo> #11449
19:18:55 <mttp> A windows user said that Windows 8.1 Maintenance Centre told him that Tor Browser was not working.
19:19:05 <mttp> In the Reliability tab
19:19:19 <mttp> I'm not sure what that means--that was all the information I got on that one
19:19:28 <mttp> GeKo: thanks
19:19:58 <Yawning> mttp: oh since you're here, can I close that obfs4 bug you filed a long time ago re reserved ports?
19:20:27 <Yawning> the readme shows how to setcap the executable and the torrc one liner to tell it what port obfs4 should run on
19:20:50 <mttp> Sure--did you implement it or what (I hadn't been following the development status lately)
19:20:51 <Yawning> (and to setcap the binary or not should be the sysadmin's choice)
19:21:00 <mttp> oh cool
19:21:06 <Yawning> you sudo one command after installing it
19:21:21 <Yawning> tell tor "yeah obfs3 or 4 should be on port <whatever>" and it automagically works
19:21:39 <Yawning> my test bridge runs obfs3 on 80 and obfs4 on 443 using that mechanism
19:22:01 <Yawning> no port forwarding or anything, naturally
19:22:40 <mttp> The help desk gets emails several times a week from people behind "Cyberoam" firewalls who can't access Tor.
19:23:00 <mttp> Most of the time I respond to these with "Sorry Tor can't circumvent all firewalls.
19:23:27 <Yawning> if it's just need bridges on common ports, obfs4proxy should help a lot for that
19:23:29 <mttp> Meek, flashproxy, scramblesuit, FTE, don't succeed in this case"
19:23:49 <mttp> maybe so. That's not specifically a browser issue, but I wanted to bring it up.
19:24:30 <mttp> I'm wondering how hard it would be to catch certain Tor warnings and dsiplay a a windowed error message.
19:24:38 <mttp> For example Clock skew
19:24:43 <Yawning> hmm
19:25:34 <Yawning> fairly trivial, since the log messages are accesible from the control port
19:25:48 <Yawning> (oh, I'm not like, spewing noise into the tor browser meeting right? >..0
19:25:53 <GeKo> mttp: I read Colin's report today and there he said "Many users asking about using plugins in the Tor Browser"
19:26:04 <GeKo> do they mean plugins or extensions?
19:26:28 <GeKo> and what is the usual help desk reply?
19:26:31 <mttp> ally
19:26:38 <mttp> Both actually
19:27:29 <Yawning> (in fact or-applet echos the tor log into libnotify, which isn't a dialog box, but is similar in concept)
19:27:36 <mttp> For plugins, I direct them to https://www.torproject.org/docs/faq#TBBFlash
19:27:49 <MarkSmith> regarding displaying some tor warnings as alerts or similar, please file a ticket.  Bonus points if someone can comment in the ticket to let us know if Vidallia did anything special for certain warnings.
19:27:52 <mttp> even if it's a question about Java or MS Silverlight
19:28:16 <MarkSmith> But beware that Tor Launcher still misses early tor messages.
19:28:46 <Yawning> MarkSmith: there's a race there because the launcher needs to connect to the control port right?
19:29:28 <Yawning> wonder if there's a easy way to fix that
19:29:31 <MarkSmith> Yawning: right.  See #10059
19:29:49 <mikeperry> mttp: btw, the PT people are probably interested in the cyberoam issue. I am wondering if it is a local, on-computer thing, or a network device, or both. perhaps get more details and show up at their meeting?
19:30:41 <mttp> For extensions I will tell them that Adblock, Ghostery and Disconnect are not necessary with Tor Browser and direct them to the Tor Browser design doc
19:30:58 <Yawning> mikeperry: yes, we are interested
19:31:00 <mttp> Those are the most commonly asked about extensions
19:31:08 <GeKo> yes, and extensions can basically be as dangerous
19:31:38 <mttp> For non-privacy related extesnions I'll pretty much repeat https://www.torproject.org/docs/faq#TBBOtherExtensions
19:32:27 <GeKo> ok
19:32:37 <Yawning> mttp: If I could get more information about this cyberroam thing, it'd be great
19:33:06 <mttp> mikeperry: cyberoam is a NAT from what I can tell. It requires the (usually universioty students) to access the web through a set proxy
19:33:53 <mttp> And they do DPI
19:33:59 <mttp> according to http://bluecabinet.info/wiki/Cyberoam
19:34:02 <Yawning> does it do nasty things like TLS main in the middle?
19:34:32 <mttp> Yep. One student said he had to use his university's ssl_certs.pem file
19:34:49 <Yawning> ahhh
19:34:53 <murb> evil!
19:35:20 <murb> i wonder what happens if you do ssl in ssl?
19:35:40 <mttp> It's quite sad turning all those ppl away. Some of them are like "It's urgent ! I have an assignment due and I'm being blocked from doing research!"
19:35:52 <mttp> murb: what do you mena?
19:36:07 <murb> mttp: so they mitm the first layer.
19:36:17 <Yawning> depending on how good their dpi stuff is, meek might be able to get through that
19:36:37 <Yawning> murb: then the dpi code will probably be like "this isn't http plaintext, denied"
19:36:58 <mttp> After the 4.0-alphas came out I asked some cyberoam-affect users to try it and so far no on meek-google and meek-amazon
19:37:26 <mikeperry> could just be #12381?
19:37:31 <mikeperry> if they also need to set a proxy?
19:37:49 <Yawning> hmm
19:37:58 <Yawning> no, meek doesn't use that code
19:39:47 <mttp> What other information should I try to get afrom Cyberoam victims?
19:41:25 <Yawning> hmm
19:41:38 <Yawning> I think I know why meek pukes
19:41:58 <Yawning> ideally a shell with a dev envionment, but that's prolly asking too much >.>
19:43:23 <mttp> Not sure any of these computers would be reachable by SSH anyways. They can't open firewall ports
19:43:34 <murb> cyperroam seem to have a try&buy option...
19:44:15 <mttp> It seems to be university campus deployment mostly
19:46:21 <mttp> Heh it'd be intersting to social engineer them like"I 'm thinking of getting your product but can it stop ALL tor users? Even those Pluggable transport users I read about in the news?"
19:46:24 <murb> they seem to do the virtual appliance thing, just thinking this would be much easier to work on if we had a demo estup.
19:47:08 <Yawning> meek's tor-browser helper thing that we use for distinguishability reashons doesn't trust the system cert store right?
19:47:22 <mikeperry> right
19:48:04 <Yawning> meek-client without using the helper will, which will solve the mitm cert breaking shit
19:48:11 <Yawning> though that's less secure
19:48:56 <Yawning> the evil cyberroam thing could impersonate the guard if we trust their cert (and the go tls client is a bit... distinctive)
19:49:42 <Yawning> but if I were in that sort of enviornment, I'd try meek-client with the evil cert loaded, and butchered to log errors
19:49:55 <Yawning> and investigate from there
19:50:19 <murb> okay, they seem to be up for letting people trial their software fo evaluation purposes :)
19:50:27 <Yawning> oh ho ho
19:50:45 <mikeperry> ok. can we table this for after the meeting?
19:50:51 <Yawning> (eep sorry)
19:50:52 <mikeperry> anything else TBB-specific?
19:51:11 <mttp> no that's all I ahve
19:51:39 <mikeperry> I will try to merge stuff tagged with https://trac.torproject.org/projects/tor/query?keywords=~MikePerry201409R&status=!closed before I leave for the OTF thing, but I might not make it
19:51:56 <mikeperry> is anything blocking people that I should look at ASAP?
19:52:16 <GeKo> no
19:52:20 <Yawning> neg
19:52:47 <MarkSmith> np
19:52:51 <MarkSmith> err.  no
19:53:21 <mikeperry> ok
19:54:30 <mikeperry> I think that wraps it up then
19:54:34 <mikeperry> #endmeeting *baf*