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*