17:59:09 <mikeperry> #startmeeting
17:59:09 <MeetBot> Meeting started Mon Sep  1 17:59:09 2014 UTC.  The chair is mikeperry. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:59:09 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
17:59:45 <mikeperry> ok, so I guess today is technically labor day, which I guess is a US holiday that I think means that you're supposed to have just seen a big wooden man light on fire or something
18:00:02 <mikeperry> so hopefully everybody did that, anor/or is going to be lighting smaller fires later on
18:00:12 <GeKo> ha
18:00:51 <mikeperry> but since I got up anyway, I guess we should try to have this meeting and see what happens
18:01:33 * arthuredelstein spontaneously combusts
18:01:55 <mikeperry> so last week I finished the high-level Firefox feature review for ESR31 (#12621)
18:02:21 <mikeperry> I also did a bunch of review to get as much stuff into 4.0a2 and 3.6.5 as possible, and then tagged and built those releases
18:04:08 <mikeperry> this week I need to write the TBB status report, get these two releases out, and then focus on FF31ESR
18:04:27 <mikeperry> probably review the networking code, and file tickets for stuff based on that and #12621
18:04:49 <mikeperry> we also should tag this months tickets, focusing on ESR31 items
18:06:06 * isis reminds the still burning arthuredelstein to do sex, drugs, and rock&roll^W^W^W^Wstop, drop, and roll
18:06:52 <mikeperry> arthuredelstein: I reviewed your circuit isolation stuff, but I decided to hold off on it. I think we want to actually use getFirstPartyUri instead of the "first stream event is probably the url bar" approximation
18:07:04 <mikeperry> there also are navigator events you can listen to for url bar changes
18:07:14 <mikeperry> that might be a better route also
18:07:44 <mikeperry> nsIWebNavigation I think?
18:08:44 <arthuredelstein> OK. Where would you use those events?
18:10:05 <mikeperry> sorry, https://developer.mozilla.org/en-US/docs/Mozilla/Tech/XPCOM/Reference/Interface/nsIWebProgress I mean
18:10:43 <mikeperry> I think we already have one in torbutton_weblistener
18:11:15 <arthuredelstein> OK. But not quite sure how I would use it.
18:11:17 <mikeperry> we have another in torbutton_resizelistener
18:12:11 <arthuredelstein> I do think it should be easy to fix up #8641 if we can land #8405
18:12:12 <mikeperry> basically that is what will tell you the url bar has changed and that the circuit UI needs to be updated
18:12:49 <arthuredelstein> Aha, you mean switching between tabs?
18:13:23 <mikeperry> so for the alpha series, we can cheat and apply whatever form of #8405 we think we'll need, and see how it works out. so you shouldn't feel blocked on needing Tor support to do things the right way
18:13:50 <mikeperry> I think that adding the u+p to circ events might be enough
18:14:11 <arthuredelstein> Yes, I think the current patch I have on #8405 should work fine.
18:14:37 <arthuredelstein> So I'll rewrite my #8641 patch to use that
18:15:13 <arthuredelstein> While we're on the subject, did you have any thoughts on #3455?
18:17:34 <mikeperry> the new API seems useful and probably the right way to do things for a world with a proper anonymous mode in Firefox
18:17:40 <mikeperry> and I have wanted an API like that for a while
18:18:12 <mikeperry> I cringed a little bit at having another one of these filters though, both for performance reasons, an concerns about how it will need to behave in a multiprocess/electrolysis world
18:18:30 <GeKo> *nods*
18:19:16 <mikeperry> but I guess we can cross that bridge when it starts burning? probably worth having someone who knows e10s at Mozilla look at the API and comment on its perf impacts and general e10s support
18:19:35 <GeKo> that would indeed be a good idea
18:21:18 <mikeperry> I think all of this work probably should wait until we get ESR31 solid, though
18:21:39 <mikeperry> in general you've been doing a lot of great work, arthur, and it's a little hard to keep up :)
18:22:00 <arthuredelstein> Thanks ;) No worries!
18:22:07 <arthuredelstein> I kinda doubt there is a performance impact
18:22:13 <arthuredelstein> but there is a complexity impact for sure
18:22:31 <arthuredelstein> Ideally we would drop the old proxy filter, but it probably breaks a bunch of extensions including SSL Observatory.
18:23:10 <mikeperry> yeah, the told one is a totally crappy API, but lots of people ended up trying to hack a way around its crappyness and use it anyway
18:23:27 <mikeperry> foxyproxy is probably th worst offender in that regard
18:23:39 <GeKo> *blushes*
18:24:25 <arthuredelstein> :) GeKo, if you have any  special hacks that will let us use the existing proxy filter, I'm very interested! ;)
18:24:29 <mikeperry> GeKo: heh, my dislike of foxyproxy goes back many years. for all I know, you made it less bad than it used to be
18:25:18 <GeKo> arthuredelstein: no, that is not going to work
18:25:36 <GeKo> we need channels and it is working with URLs
18:25:41 <arthuredelstein> :( Yeah I didn't think so. Spent days trying.
18:26:55 <mikeperry> so anyway, yeah, we should submit this API with our patch set as soon as we get everything on to ESR31, and see what Mozilla says about it
18:27:16 <arthuredelstein> OK, cool
18:29:37 <mikeperry> so I guess we should continue with the normal meeting format. sorry for the diversion
18:31:08 <mikeperry> who wants to go next? or I guess arthur can talk more about the rest of the stuff he's been working on?
18:31:45 <GeKo> I can go.
18:32:23 <GeKo> So, I worked mainly on two things: Getting the ESR 31 to compile and on the security slider UI.
18:33:02 <GeKo> wrt the latter: I made some good progress but did not finish it for review due to release related things and other stuff popping up.
18:33:42 <GeKo> but it should be possible to have it ready by the ened of this week or by next Monday.
18:34:05 <GeKo> compiling ESR 31 works so far. I fixed the annoying Windows issue.
18:34:23 <GeKo> now a packaging problem needs to get solved and the libfaketime issue
18:34:53 <GeKo> the latter causes Firefox to be built twice usually and is breaking the build near the end
18:35:32 <GeKo> I am currently experimenting by excluding the build itself from being under libfaketime; we'll see if that helps
18:36:01 <GeKo> then I tried a hotfix for #12103 which is, alas, only partially working.
18:36:27 <GeKo> that's all for me containing with toolchain fun and #9387 for this weel.
18:36:30 <GeKo> *week
18:36:58 <mikeperry> in what way is it partially working?
18:37:22 <GeKo> we only get partial RELRO not the full one according to checksec
18:37:54 <GeKo> I have not had time to dig deeper yet
18:38:14 <mikeperry> ok
18:38:30 <mikeperry> I wonder what we should do about the changelog?
18:38:58 <GeKo> we should leave it
18:39:08 <GeKo> we added RELRO back but not the full one :D
18:39:13 <mikeperry> ok
18:40:44 <xiando> mikeperry: could I ask you a question privately?
18:41:17 <mikeperry> xiando: we're in the middle of a meeting, I might not be fully responsive, depending..
18:41:22 <mikeperry> but go ahead
18:42:52 <tjr> I can go next if GeKo is done
18:43:45 <GeKo> yes, I am
18:44:11 <tjr> I figured out a lot of my build problems, and successfully built Linux/Mac/Windoes vanilla builds.
18:44:28 <tjr> Then I enabled the memory replcaement library and built that on Linux, but got hung on Mac and Windows.
18:45:16 <mikeperry> sometimes the mac builds just hang, and I've also had gcc rndomly fail to build on windows sometimes to :/
18:45:30 <tjr> Currently working on Mac.  It seems that in order to have the memory replacement library, i need jemalloc.  And jemalloc on Mac requires pthreads, which is failing =/
18:45:59 <tjr> I believe I also need a 64 bit Mac build (which would be good regardless for ASLR)
18:46:01 <mikeperry> restarting the build usually fixes it (if you use 'make build' or 'make build-alpha')
18:46:31 <tjr> So I'm in Step 3 and inside the VM trying to compile vanilla TBB (no memory replacement/jemalloc) with an x86_64 arch and we'll see how that goes
18:47:06 <mikeperry> for mac build issues, the person to talk to is Ray Donneley. he basically wrote our toolchain for macos
18:47:20 <mikeperry> he is very helpful
18:47:20 <tjr> I'm not sure why pthreads is missing but it might be the mac toolchain, it might be jemalloc's configure isn't looking for it correctly, it might be something else.
18:47:37 <tjr> Cool.  I will collect some more data and... email him?  What's the best way to contact him?
18:47:57 <mikeperry> Ray Donnelly <mingw.android@gmail.com>. you can cc georg and I and say you're working with us?
18:48:15 <tjr> Will do!
18:48:20 <GeKo> thx
18:49:20 <tjr> Aside from that, I've been pretty lost with how to officially tag and develop.  I have a system that 'works' for me, but it will need to be better integrated with you guys once you want to test my patches.  https://github.com/tomrittervg/tor-browser/releases
18:50:24 <tjr> That's all for me
18:50:34 <mikeperry> yeah, it is a bit painful to develop in gitian, too.. in some cases it is useful to just try to build locally until you get a firefox build that seems to be working how you want.. that way you don't have to rebuild it from the top each time
18:50:52 <asn> tjr: thx for working on this stuff btw :)
18:51:03 <GeKo> yeah
18:51:08 <mikeperry> https://trac.torproject.org/projects/tor/wiki/doc/TorBrowser/Hacking#BuildingJustFirefox
18:51:39 <mikeperry> tjr: yes, thanks a lot. very glad you're still poking at this
18:51:56 <tjr> mikeperry: That's basically what I'm doing, just inside the mac os build vm
18:52:22 <mikeperry> ah, ok good. so you've discovered on-target and friends. cool
18:52:24 <tjr> I've also edited the descriptors to pull the .so out of the build when finished (which seems to work for linux, but yet to be tested for mac/win)
18:53:37 * tjr is going to be less responsive once someone else starts as I owe someone a meal
18:54:48 <mttp> I can do support stuff
18:55:10 <mttp> Many users ask about the costs and benefits of Javascript. The security slider could go a long away to assuage the numerous concerns, but users need access to clear information about their level of risk when using Tor Browser at each slider position.
18:56:05 <mttp> Many people are still saying. "I couldn't figure out to how to get my Tor log." when they experience problems. I think this is because Tor is hanging for them at the progress bar rather than returning to the dialog with the "Copy Tor log to clipboard".
18:56:22 <mttp> button
18:57:14 <mikeperry> are these censored users?
18:57:26 <GeKo> mttp: calculating the level of risk for each position is tricky let alone getting that communicated in laymen terms
18:57:33 <mttp> Not neccessarily, often they are firewalled users
18:58:11 <mttp> GeKo: or at least some level of information
18:58:46 <GeKo> yes, I am aware of that. and hopefully we come up with a good solution
18:59:21 <mttp> Meek-amazon, meek-google, FTE, flashproxy and the rest still do not always provide a circumvention solution  for many users behind restrictive firewalls
18:59:40 <mikeperry> mttp: hrmm.. the progress bar should still time out I would think. tor gives up eventually.. I guess it may take minutes though?
19:00:03 <mikeperry> maybe some stages don't time out at all.. not sure if this is a tor bug *and* a tor launcher UI issue, or what
19:00:57 <mttp> I'm only guessing at the reason. I still see the question of "how do I get the Tor log?" not infrequently, and I'm not sure why
19:01:45 <mttp> "It's in the lower left corner of the window you get after "Connecting"
19:01:49 <mttp> "
19:01:59 <mttp> "I still don't see it"
19:02:02 <mttp> etc
19:02:28 <GeKo> the tor log question only comes up often during due to start-up issues?
19:02:43 <GeKo> s/during//
19:03:05 <mttp> Yes, this would be someone starting Tor for the first time, or trying to rather
19:03:15 <GeKo> ok
19:05:20 <mttp> failure strings that reference Firefox still confuse users.
19:05:32 <mttp> "I downloaded Firefox and it still didn't work!"
19:06:00 <mttp> "I have never used Firefox in my life! Why is it on my computer?!!"
19:06:30 <mikeperry> if you can find those specific strings, mention them in a tbb-branding bug, or file a new tbb-branding bug? (and also tag it with the tbb-helpdesk-frequent and tbb-usability tags)
19:06:46 <mttp> sure
19:08:17 <mttp> I'll only be describing where they are in the interface, not in the code. I think I searched for them in the Firefox code before and found locating them surprisingly dificult.
19:08:33 <GeKo> sure
19:09:28 <mttp> As far as Windows Tor bundle stuff, I'm not sure how much more effort I should put into the expert bundles... erinn says she is working on an entirely new nsi script, so any patches I make wouldn't really matter since the current nsi script will soon be removed from tor.git to be replaced by some new one in builders/tor-browser-bundle.git
19:09:46 <mikeperry> yeah, she is working on a gitian descriptor
19:10:08 <mttp> Right, she seems to have it under control
19:13:23 <mikeperry> ok, who's next then?
19:13:29 * boklm can go next
19:14:15 <boklm> Last week I improved the test reports index page on http://93.95.228.164/reports/
19:14:36 <boklm> I also made the update of index pages faster (with the increasing number of reports it was taking a few minutes each time we added one, now a few seconds)
19:14:42 <boklm> and I started looking at adding tbb nightly build reports there too
19:15:00 <boklm> This week I'm planning to launch a rebuild of our tor browser patches to run mochitest tests on them (I didn't launch it yet because of the changes I was doing on the index pages)
19:15:09 <boklm> and try to add nightly build reports
19:15:31 <boklm> I also have a question about the latest alpha version string: https://lists.torproject.org/pipermail/tbb-dev/2014-September/000106.html
19:16:28 <mikeperry> yeah, you're right about the tag vs version string.. we should make them the same
19:16:49 <boklm> ok
19:16:53 <mikeperry> probably also upload builds to the tag dir, too (though I wonder what git magic lets us do that)
19:17:39 <mikeperry> I gues git tag --contains may do the trick
19:17:44 <boklm> git-describe can help us know if the current commit is a tag
19:18:56 <mikeperry> git describe --exact-match seems better
19:19:38 <boklm> yes
19:20:50 <mikeperry> or basename `git describe --all`
19:20:57 <mikeperry> which will also give us a branch, for the nightlies
19:23:02 <mikeperry> ok, I created #13015
19:23:22 <mikeperry> hopefully I will remember to do that before the next release, though this may be a hectic month
19:23:30 <boklm> ok
19:24:36 * boklm can maybe provide a patch to do that
19:25:35 <mikeperry> ok. check-match.sh and upload-signature.sh are what you want to patch.. though ln5's nightly scripts repo probably will also need patching, maybe?
19:26:16 <GeKo> the scripts are in our repo already
19:26:24 <boklm> yes, I think ln5 scripts are using something different for upload
19:28:11 <GeKo> in tools/continuous-builds
19:28:44 <boklm> it seems to be tools/continuous-builds/park-nightly.sh that is used to create the directory for nightlies
19:28:52 <GeKo> yes
19:29:33 <boklm> ok, I will look at that
19:33:48 * arthuredelstein can go next if boklm is finished
19:34:03 <boklm> yes, that's it for me
19:35:04 <arthuredelstein> Last week I re-touched #8641, and I wrote patches for #10751. Then I wrote regression tests for several more patches in #12620.
19:36:08 <arthuredelstein> This week I'll try to write more regression tests, and maybe submit my C++ patches from #3455 to Mozilla to see what they think
19:36:32 <arthuredelstein> That's all for me
19:40:29 <mikeperry> cool
19:40:46 <mikeperry> I am replying to your JS hooking mail now, btw
19:40:58 <arthuredelstein> thanks!
19:41:14 <mikeperry> short answer is "maybe, but could be a sinkhole of new problems"
19:41:32 <mikeperry> I've tried the hooking approach before.. it didn't go well
19:42:21 <GeKo> I think we should not revive that and try to get a proper anon mode into vanilla Firefox for all users
19:42:31 <mikeperry> ok, so this month I think the bulk of our efforts should be focused on getting FF31esr builds. I think things like this circuit UI, and perhaps even the security slider should take a back seat
19:42:52 <mikeperry> if you haven't seen it yet, you should all take a look at https://trac.torproject.org/projects/tor/query?keywords=~ff31-esr
19:43:10 <mikeperry> there are a few tickets in there that are patches that we want to backport from Mozilla
19:43:23 <mikeperry> in particular, #11955
19:43:29 <mikeperry> and #12950
19:44:11 <GeKo> have you seen my comment on #12950?
19:44:58 <mikeperry> I thought they finally decided to land it in FF32
19:45:35 <mikeperry> oh
19:45:39 <mikeperry> that comment was from june
19:45:41 <mikeperry> I guess not
19:46:03 <mikeperry> ok, perhaps skip #12950 for now then
19:46:07 <GeKo> no, and there were crashes involved which is why it got backed out long ago
19:47:39 <mikeperry> GeKo: is it OK if I only tag #12460 with the TorBrowserTeam201409 tag, and untag the children?
19:48:17 <mikeperry> I want to make this ticket list more managable to look at
19:48:21 <GeKo> that's enough, yes
19:48:42 <mikeperry> and I think I will tag the security slider and the circuit isolation stuff with October, though we can add it back in if the EsR stuff goes well
19:49:49 <mikeperry> though I guess GeKo you probably work on the slider while waiting for ESR31-related builds to complete?
19:50:17 <GeKo> that's what I currently do
19:50:25 <GeKo> so, it fits pretty well
19:50:37 <GeKo> but I can work on other ESR 31 related things while waiting
19:54:16 <mikeperry> ok. whatever works. don't let me mess up your workflow :)
19:55:22 <GeKo> no problem. I'll look at the esr 31 tickets tomorrow closer and see what I find
19:55:58 <mikeperry> arthuredelstein: let me know when you think your esr31 branch is semi-solid, and I will make a new remote and squash it down, clean it up, etc
19:56:30 <mikeperry> as soon as that branch is ready, each patch owner should be looking over their patches to veryify that nothing substantial changed
19:56:40 <mikeperry> which I guess is probably mostly myself and pearl crescent
19:56:44 <arthuredelstein> OK, will do. Difficult to know what semi-solid is, though ;)
19:57:10 <arthuredelstein> Everything compiles, so it's all about code review and running tests
19:58:17 <arthuredelstein> So if you feel like squashing it now, that's fine with me
19:59:10 * GeKo is going afk
19:59:43 <arthuredelstein> One thought that occurred to me is that it might be better to keep regression tests as independent patches. That way, if we land a patch at Mozilla, we can hold onto the regression test in tor-browser.git.
19:59:46 <GeKo> but I'll read the backlog
20:00:18 <mikeperry> GeKo: ok cool. sorry we ran so long today
20:00:58 <mikeperry> arthuredelstein: hrmm.. I think we probably want to land those tests with mozilla too though. we want them to know when they break our stuff in their own testing framework+tree
20:01:47 <arthuredelstein> Yes, keeping them on both places is probably best
20:02:13 <arthuredelstein> *in
20:02:42 <arthuredelstein> I just want to be able to catch any future bit rot that happens at Mozilla.
20:04:19 <boklm> what do you mean by keeping them in both places ?
20:04:32 <arthuredelstein> Both in mozilla-central and tor-browser.git
20:05:03 <mikeperry> arthuredelstein: can you see if you can get #12523 and #11955 working in your repo?
20:05:14 <arthuredelstein> sure
20:05:17 <mikeperry> there is also https://bugzilla.mozilla.org/show_bug.cgi?id=418354, but it looks like that one is less well-baked
20:05:32 <arthuredelstein> I'll have a look at that one too.
20:05:56 <mikeperry> I thought I created our own trac ticket for that, but I can't seem to find it now
20:06:31 <mikeperry> that mixed content blocking bug is preventing a ton of HTTPS_Everywhere rules from working correctly :/
20:07:02 <arthuredelstein> interesting
20:07:53 <arthuredelstein> the bug or the patch?
20:08:41 <mikeperry> the bug does
20:08:47 <mikeperry> the patch would fix it
20:09:27 <mikeperry> ok, I think that pretty much wraps it up for today
20:09:40 <mikeperry> I will retag everything for this month
20:09:57 <mikeperry> also try to get your status reports in, so its easier for me to write the team report
20:10:16 <msvb-lab> mikeperry: You want us to report individually, or send them to you?
20:10:30 <mikeperry> report individually to tor-reports@lists.torproject.org
20:13:42 <mikeperry> ok, I think that's it. thanks everyone!
20:13:56 <mikeperry> #endmeeting *baf*