14:59:19 #startmeeting 14:59:19 Meeting started Fri Jul 25 14:59:19 2014 UTC. The chair is mikeperry. Information about MeetBot at http://wiki.debian.org/MeetBot. 14:59:19 Useful Commands: #action #agreed #help #info #idea #link #topic. 14:59:50 TBB meeting time. let's get started. 15:00:59 Hi all 15:01:21 Hello folks. 15:01:37 This week I drove the 3.6.3 release; got a pipelining test build to mjuarez for traffic fingerprinting experimentation; did some work on our funding proposal; debugged sudo+LXC build VM issues on our AWS host for dcf1; and wrote an outline of the stages for the security slider in #9387. 15:01:51 Next week I hope to get 4.0-alpha-1 out, and start some builds with vanilla FF31ESR right after that. I may also begin reviewing the Firefox developer documentation. 15:03:23 oh, I also want to add the roadmap from the dev meeting to the sponsorp page 15:03:53 "reviewing the Firefox developer documentation" for FF 24 -> FF 31 things that may affect us or ? 15:04:03 yeah 15:04:11 got iot 15:04:15 got it 15:04:59 that's it for me I think 15:07:44 * MarkSmith can go next 15:07:47 oh, I may also circulate the funding proposal next week before we submit it 15:08:00 it's basically supposed to be a renewal of our current one 15:08:23 This week, Kathy Brade and I added support for symlinks to the Firefox updater (#12647). 15:08:34 Symlinks are used by meek on Mac OS. We still need to do a little more testing, but we are nearly done. 15:08:44 While working on this, we rebased our entire set of updater patches to the tor-browser-24.7.0esr-4.x-1 branch. 15:08:56 We made a fix for #11199 (providing a way to restart tor from within Tor Launcher) 15:09:05 and we commented on #8641 (circuit status UI). 15:09:19 The next steps for #4234 are to create (or find someone else to create) an update responder (#12622) 15:09:33 and to merge the Firefox and TBB build process changes (after TBB 4.0a1 ships. 15:09:43 We will continue to work on Tor Launcher items as we have time. 15:09:54 I think that's all for us. 15:11:36 ok cool 15:12:17 hopefully the symlink thing was not a lot of work just for meek. I guess it will be useful in the future though 15:12:33 not too bad… more time testing than coding probably 15:13:04 might be generally useful for Mozilla too I suppose (we only tested on Mac OS so far but should work on Linux too) 15:15:09 do you know if the responder script's output can/must be signed by anything? 15:16:10 I am not sure who we have that would do that work at the moment 15:16:16 I don't think it can or must be signed but we can double-check 15:16:46 I think boklm does python, but he's out today. 15:16:59 Kathy and I may just have to do it, or we can do something less elegant in the short run (e.g., figure out a way to use status files served over https) 15:17:51 yeah, I guess it depends on at which stage we intend to support incrementals 15:18:27 right 15:19:30 Should we ask boklm to work on it or consider doing so? 15:20:49 we can ask him if it would be easy for him. I am also wary about making sure it is done both simply and securely 15:21:03 OK 15:21:42 We can email him and CC you. 15:22:21 ok, sounds good 15:24:37 who's next then? 15:24:40 * arthuredelstein can go next 15:24:50 This week I've been working on #8641. To that end I've written an asynchronous ControlPort client module based around Mozilla sockets, and I put together a simple UI mockup. 15:25:25 Also, I annotated each commit message in tor-browser.git with a Bug #, thinking that might help with rebase to FF ESR31 (https://github.com/arthuredelstein/tor-browser/commits/bugIDs-tor-browser-24.7.0esr-4.x-1) 15:25:56 Next week I'll try to put together an #8641 prototype 15:26:09 Any further feedback welcome. 15:26:12 That's it for me. 15:26:31 thanks for the annotation 15:26:42 did you see the existing controlport code in tor launcher? 15:26:55 https://gitweb.torproject.org/tor-launcher.git/blob/refs/heads/master:/src/components/tl-protocol.js 15:27:33 No, sad to admit :( 15:28:41 arthuredelstein: That's a beautiful circuit display dialog, hope it works out. 15:28:53 ideally we would use that if possible, I think. and possibly extend it as needed 15:29:38 yes, I did like it. I am trying to think about how to represent the edge cases where more than one circuit ends up getting used. the case lunar brought up is one of them, but there may be others.. 15:30:39 hopefully they will be uncommon such that we could make some sort of extended display in those rare cases without it being too busy 15:30:56 Yes, I think we could display additional circuit diagrams, only when necessary 15:32:22 another place for more details would be somewhere in the Ctrl+I window 15:33:04 Lunar^: good point 15:33:25 How often do people need to see all of the details? 15:33:40 when tracking a bad exit? 15:33:45 if something breaks or acts strangely and they need to report a bad exit 15:33:49 If often, make it easy to find. If not, it can be harder to find/harder to get at. 15:33:58 or try to diagnose a geo-locational issue 15:34:13 I am not sure most people will find it in Page Info 15:35:11 Another option is to place a "More info..." button in the TorButton popup 15:36:04 Kathy suggests putting "Tor Circuit" in the menu and having the info show up when you choose that (hierarchical menu) 15:37:10 As a dialog or a popup submenu? 15:38:18 She was thinking submenu; clicking on the submenu contents would open a larger, persistent window 15:38:56 I would say there are a lot of UI choices and we probably won't get it right the first time ;) 15:39:09 Of course :) 15:39:16 I believe the general case to be curiosity and geolocation-related issues. So having the circuit used to fetch the page like in the mockup would probably work great. With a “more info” link that would open a dedicated tab in Page Info, it would probably work out nicely for power users 15:39:45 well a persistent window might get confusing because it would apply to either the current focused tab (and need to get updated), or be stale 15:40:41 yeah, I think it is also important to keep the general cases very simple, clean looking, and readily available 15:40:43 mikeperry: good point regarding persistent window. Contents wouid need to "follow 15:40:48 the tab" 15:40:54 Maybe a persistent window would need to show all circuits for all domains. More like vidalia. 15:41:33 But in any case, I think a persistent window can wait for a future iteration 15:43:01 yeah 15:45:18 ok, I will try to have a look at the rest of your tor control port code next week 15:46:07 mikeperry: Do you mean #3455? 15:46:58 yeah 15:47:24 My control port code is at https://github.com/arthuredelstein/controlPort/blob/master/controlPort.jsm, but probably we won't use it :( 15:49:12 Anyhow, that's all for me. :) 15:49:17 ok 15:51:23 do we have anything from support? or a GeKo? 15:51:47 I'm here today 15:53:12 any new issues? 15:53:13 One issue I've seen very recently is users who say that Tor Browser will work for ~3 hours and then quit. It sounds like a "TOR HAS STOPPED WORKING IN THE BROWSER " issue. I've asked the users to file bug reports. Not usre if any have been filed though. Sounds like a WIndows issue so far 15:53:48 And if Tor is deleted and reinstalled, the same thing happens. Works for ~3 hrs then quits 15:53:54 are they PT/bridge users? 15:54:27 Sounds like no bc neither of the users mentioned bridges or PTs or censorship 15:55:06 are they clicking on stuff during the 3 hours, or just letting it sit? 16:03:30 Did OFTC just hiccup? Are we online? 16:03:38 net split 16:03:58 "online" is really subjective 16:04:09 http://en.wikipedia.org/wiki/Netsplit 16:05:56 infinity0: I think you're right. 16:07:59 ok, well I think next steps is to try to get AV info, and to ask the user to open up the process manager to see if tor.exe is still running 16:07:59 ok. If I find out AV info, should send that to the ML or just remember next time we talk on IRC or what? 16:08:00 (like for example if the users have the same AV program) 16:08:00 or file a bug if it does end up sounding like a tor issue 16:08:00 gotcha 16:08:00 but my bet is on AV doing something. knowing if tor.exe is still running might clue us into exactly what 16:08:41 if tor.exe is still running that would make you think it's not a Tor issue, yes? 16:09:52 yeah, it would make me suspect some kind of firewall thing affecting the control port connection like roger suggested 16:10:05 at least, it would be one more datapoint in that direction 16:10:17 ok moore details soon hopefully 16:10:43 ok. anything else? anyone else? 16:11:08 Hi Mike 16:13:52 hey 16:13:58 @mikeperry: hi 16:14:12 hai 16:14:27 vinod will be around in a few … 16:14:30 mikeperry: i feel like an old curmudgeon saying "problems on windows? i bet your antivirus is fucking with you" 16:15:00 but i've been right just enough to keep saying it :/ 16:15:12 ok, I think this means the meeting is over then? I need to vanish for a bit, will be back later 16:15:36 mikeperry go time for a quick question first? 16:15:47 got time* 16:15:47 sure 16:16:18 mikeperry: I have one also, is there a ETA on the blog post about the iSEC report? 16:16:31 Does building Tor Browser still require Ubuntu 12.04? I thought I heard something about 14.04 support, but not sure if that is still inprogress 16:16:53 tjr: it's on the pile. I think we have everything in the bugtracker, but I need to gether all the tickets and make sure we list them all in it, etc 16:17:09 mttp: I am building from 14.04 with KVM 16:17:22 LXC support may be broken on 14.04 though 16:17:24 mttp: can you add a todo item to make https://www.torproject.org/projects/torbrowser-details.html.en#build not lie so much? 16:17:36 (maybe the answer is to make the page stop existing) 16:17:51 Okay. We have a blog post pretty ready to go, but we'll need to add in notes specific from yours. If you publish duing the Black Hat/Vegas circus I won't be able to publish in a timely manner. (It would also take a lot of focus away from it) 16:17:59 mttp: (it's linked from the bottom of https://www.torproject.org/projects/torbrowser.html.en) 16:18:02 Second question is is Virtual box on the list of support VM environemtns? I know KVM is "the right way" 16:18:21 armadev: I'll check it out 16:18:39 tjr: ok. I can send you a draft/export of our post before it goes live, to give you time to review/comment 16:18:55 mikeperry: That'd be great, thanks 16:18:58 mikeperry: but I though there were other options supported 16:19:06 for some reason 16:19:42 mttp: You might need to run with 'TORSOCKS=' to avoid svn(1) hangs on 14.04 AMD64 using KVM. 16:20:02 mttp: ...as in https://trac.torproject.org/projects/tor/wiki/doc/TorBrowser/BuildingWithGitian#FlawedSoftwareHangs 16:20:12 armadev: ooh that is old. Yes I can update it 16:20:18 mttp: ...and for your second question regarding VMs might want to see https://trac.torproject.org/projects/tor/wiki/doc/TorBrowser/VMSetup 16:20:18 msvb-lab: ah, yes, I did run into that. I had to upgrade torsocks to the 2.0 series 16:20:46 gitian supports virtualbox as an option instead of KVM now, though I have not tried it 16:21:08 might be worth seeing if it works on machines without kvm support 16:21:28 mikeperry: Oh nice, would be great to write into a doc (your hacking one?) how to upgrade tools properly (no user interaction.) 16:21:29 but probably requires some new env vars to be exported, and perhaps options to be passed through 16:22:10 yes, possibly 16:23:31 ok. I think it's time to call it 16:23:36 #endmeeting *baf*