18:00:34 <mikeperry> #startmeeting app-dev
18:00:34 <MeetBot> Meeting started Mon Aug 31 18:00:34 2015 UTC.  The chair is mikeperry. Information about MeetBot at http://wiki.debian.org/MeetBot.
18:00:34 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
18:01:29 <mikeperry> Welcome to the Tor Applications dev meeting. Let's go through the standups
18:02:16 <mikeperry> Last week, I helped Georg get 5.0.2 and 5.5a2 out. I also booked a month's worth of travel, and dug out from underneath some paperwork.
18:02:25 <mikeperry> This week, I will be writing our status reports. I will also move our tickets over to September, and have a look at the roadmap as I do so. More paperwork awaits! At least the releases may be finally slowing down.
18:03:08 <mikeperry> I think that's it for me for no
18:06:30 <huseby> :)
18:07:16 <GeKo> here is what i did:
18:07:27 <GeKo> i worked on a variety of things.
18:07:55 <GeKo> a big chunk was the things involved in the release
18:08:20 <GeKo> then i worked on #13512, #14625 and #16855
18:08:49 <GeKo> additionally i found time to fix #15538 it seems which is nice
18:09:13 <GeKo> so, the plan here is  to sign the alpha bundles from a linux box next time
18:09:42 <GeKo> and if that is working we can get the autheticode thing used on our signing machine
18:09:53 <GeKo> which means one bottleneck less, yay!
18:10:24 <huseby> here is what I did:
18:10:27 <GeKo> next week i plan to document and test my setups for #15538 (further)
18:10:34 <huseby> whoops :)
18:10:45 <GeKo> then i work on #16444, 16909 and #15578
18:11:02 <GeKo> #16909
18:11:35 <GeKo> that's it for me for now
18:11:45 <GeKo> huseby: now, go ahead :)
18:12:20 <huseby> sure
18:12:25 <huseby> so last week:
18:12:41 <huseby> got https://bugzilla.mozilla.org/show_bug.cgi?id=232227 out for final review and landing
18:13:03 <huseby> got https://bugzilla.mozilla.org/show_bug.cgi?id=962358 ready for review...I have about 10 minutes left with the unit test, so expect that today
18:14:15 <huseby> so then I'm going to create bz bugs for and start in on #15502, #16300, #13670, #15703
18:14:46 <huseby> I'm also meeting with Mozilla engineers about our contextual identity/containers to do the transition now that our intern is leaving us
18:15:04 <huseby> I booked travel for meetup in berlin
18:15:39 <huseby> i need to schedule a meeting with some of you to talk about tor's requirements for contextual identity/containers
18:15:45 <huseby> that's it for me
18:15:48 <huseby> next?
18:15:56 <arthuredelstein> huseby: Any day this week works for me, btw
18:16:04 <huseby> k, thanks
18:16:37 * arthuredelstein can go
18:16:44 <arthuredelstein> Last week I worked on a patch for #15493.
18:16:49 <arthuredelstein> I tracked down the bug causing #15493 and filed https://bugzilla.mozilla.org/show_bug.cgi?id=1198559
18:16:52 <GeKo> huseby: what do you mean by start on these bugs?
18:17:27 <GeKo> huseby: are those bug fixes the next ones you want to upstream?
18:18:16 <huseby> GeKo: yes, the next ones I want to upstream
18:18:35 <GeKo> okay. what we really, really need for those and others is https://bugzilla.mozilla.org/show_bug.cgi?id=962326
18:18:38 <GeKo> fixed.
18:19:00 <GeKo> that needs to come first in order to get the other ones fixed on Mozilla's side
18:19:30 <GeKo> it needs to get updated with all the new stuff though
18:20:00 * GeKo is quite now
18:20:09 <huseby> GeKo: alright, I moved it up to the next on the list
18:20:17 <GeKo> thx
18:20:20 <arthuredelstein> Also, those bugs probably depend on our discussion regarding containers, right?
18:20:35 <GeKo> maybe, probably
18:20:46 <huseby> GeKo | it needs to get updated with all the new stuff though
18:20:49 <huseby> what new stuff?
18:21:04 <mikeperry> what happens with the new #15493 implementation if you have multiple tabs open to a site?
18:21:23 <mikeperry> does the circuit status get updated for all of them if the circuit changes?
18:21:30 <huseby> arthuredelstein: not really, the isolation stuff on our side has been around origin attributes (a.k.a. changing the hash function inputs)
18:22:36 <huseby> arthuredelstein: my first step was to see how they affect the containers stuff and come up with a plan we can discuss
18:24:27 <arthuredelstein> mikeperry: Good question. I'll get back to you.
18:25:03 <arthuredelstein> huseby: OK -- I think I need to study the containers stuff more.
18:25:32 <arthuredelstein> Continuing my report: I worked out the cause of #16874, and I reviewed #16775.
18:25:45 <mikeperry> arthuredelstein: yeah, I am not sure if updating already-loaded tabs is good. ideally we wouldn't change that behavior, just in case a page gets MITM'ed and then the circuit closes and it reloads in another tab, etc
18:26:37 <arthuredelstein> mikeperry: Without looking at the code, my recollection is that each tab is assined a SOCKS username:password, so that it should maintain the origin circuit info.
18:26:38 <GeKo> huseby: there have been changes to the interface with the fix for #13670/#16448 that are not included in the patch attached to the bz ticket
18:26:51 <GeKo> (sorry for the lag i had network issues)
18:26:54 <arthuredelstein> s/assined/assigned/
18:27:46 <arthuredelstein> mikeperry: But I will review the code as it stands to make sure.
18:29:29 <arthuredelstein> I also worked on #16862, which is mostly worked out.
18:29:38 <arthuredelstein> I worked on compiling an expanded list of fonts for whitelisting in Windows and Mac, which I hope to complete this week.
18:30:06 <arthuredelstein> I also plan to look at more TBB regressions and possibly work on more upstreaming to Mozilla.
18:30:11 <arthuredelstein> That's all for me.
18:30:12 <huseby> GeKo: alright, let's chat after the meeting so i have the full patch set
18:30:39 <GeKo> ok.
18:32:20 * mcs Can go next
18:32:30 <mcs> Last week, Kathy and I spent some more time on #13512, #16775 and #16778 (mostly testing plus discussion in Trac).
18:32:41 <mcs> We also looked at recent updater changes made by Mozilla engineers (we are trying to avoid being surprised by interaction between our patches and Firefox ESR maintenance patches).
18:32:47 <mcs> We did some bug triage plus some testing of Tor Browser 5.0.2.
18:32:52 <mcs> This week we plan to merge the changes for #16775.
18:32:57 <mcs> We plan to research how Mozilla handles user passwords in Sync (for #16778).
18:33:04 <mcs> And if we have more time we will work on #16910 and #16753.
18:33:10 <mcs> That's all for us.
18:35:10 * boklm can go next
18:35:57 <boklm> This week I reproduced builds of the new releases, tried to fix the GTK3 build problem on instantbird with gecko42
18:36:02 <boklm> I set svg.in-content.enabled to true for unit tests (as suggested by mcs), which fixed most errors caused by #12827, but not all: https://treeherder.mozilla.org/#/jobs?repo=try&revision=b5d8b91dac77
18:36:17 <boklm> I started looking at #16888 but did not find the problem yet
18:36:31 <boklm> This week I'm planning to look at #16888, rebase my split branch repo on 38.2.1esr and submit it to try, fix fp_navigator and https-everywhere-disabled integration tests
18:36:42 <boklm> That's all for me
18:37:41 <GeKo> what's up with those integration tests?
18:38:07 <GeKo> some false positives, i guess?
18:38:50 <boklm> yes, for https-everywhere-disabled the http site that we used for the test is now redirecting to https I think
18:39:20 <GeKo> ah, that one, okay
18:39:42 <boklm> for fp_navigator it is caused by some esr38 changes
18:40:53 <GeKo> how so given that 5.0.1 did not have this issue?
18:41:31 <boklm> 5.0.1 had it too
18:41:45 <GeKo> ah, then i looked at the wrong results, okay
18:41:57 <boklm> we also have a failure in dom-objects-enumeration, but only in the 'ko' language, because of a 'DOMConstructor' object
18:42:45 <boklm> I'm not sure why we have this for the ko language only
18:45:05 <GeKo> weird. does this happen locally on your laptop as well?
18:45:19 <mikeperry> hrmm.. I appear to have about 5 minutes of lag to IRC :/
18:45:22 <GeKo> i can try that tomorrow on my machines
18:45:35 <boklm> I did not try it yet on my laptop
18:49:28 <mikeperry> ok, any other updates?
18:51:19 <arthuredelstein> mikeperry: I just tested the #15493 patch in Tor Browser. I loaded the same site in two tabs, and then in the second tab selected "New Tor Circuit for this Site". The two tabs now show different Tor circuits in the circuit display.
18:51:30 <mikeperry> yay
18:52:31 <mikeperry> I wonder what happens if the circuit changes automaticaly due to 10 minutes going by without activity, etc
18:53:06 <mikeperry> I suppose that case is less common, and also a tricky edge case to figure out what you should display anyway
18:54:07 <GeKo> indeed
18:54:45 <arthuredelstein> This function: https://gitweb.torproject.org/torbutton.git/tree/src/chrome/content/tor-circuit-display.js#n223
18:54:52 <arthuredelstein> determines what circuit is being shown
18:55:27 <arthuredelstein> So I think unless the tab is reloaded, the display will show the circuit for whatever channel was used to load that page.
18:56:25 <boklm> GeKo: after trying now, the test fails on my laptop too
18:56:38 <boklm> actually it looks like the about:tor page is not working in the ko bundle
18:57:12 <GeKo> aha!
18:57:41 <mikeperry> well the credentialsToNodeDataMap is a global, so if another tab has activity with the same SOCKS up, then it will get updated
18:58:41 <arthuredelstein> Ah, I see what you're saying
19:00:41 <mcs> boklm: what do you mean by "not working?"  Does not load or is rendered poorly or something else?
19:02:19 <boklm> mcs: here is a screenshot after starting it: http://i.imgur.com/Vjj3WRH.jpg
19:04:34 <boklm> entering "about:tor" in the URL bar loads it correctly however
19:06:09 <boklm> so the about:tor page seems to be working, but it is not the page that is loaded when starting the browser
19:07:17 <mcs> Maybe the browser.startup.homepage pref value got translated?
19:08:23 <boklm> ah yes, it seems browser.startup.homepage has been translated
19:09:14 <arthuredelstein> mikeperry: We could change this to a "tabsToNodeDataMap" so it always shows the original circuit. Maybe that's more consistent.
19:09:37 <arthuredelstein> Of course the ideal thing is to show a full history of circuits for each tab.
19:12:27 <mikeperry> hrmm, yeah I think adding some notion of the tab to the mapping would be an imprvement.. though I agree still not ideal
19:12:41 <mikeperry> but also hard to get ideal without extra clutter/confusion
19:14:29 <mikeperry> I suppose we can think about it. if the per-tab thing isn't too hard, we should probably do it. I guess it might also want a separate commit and ticket # though
19:14:52 <arthuredelstein> I'll open a ticket about per-tab.
19:15:20 <mcs> boklm: file a ticket if there is not already one. We should not be putting things on Transifex that we do not want tranlators to touch.
19:15:51 <mikeperry> alright. well as I said I will be doing some ticket reorg over the next couple days as I write the status report. be sure to tag the new tickets with the September tag
19:16:06 <mikeperry> assuming your plan is to work on them soon
19:17:32 <mikeperry> anything else for the meeting?
19:17:53 <arthuredelstein> #16936
19:19:13 <mikeperry> cool, htanks
19:20:18 <mikeperry> ok, that wraps it up I think then
19:20:20 <mikeperry> thansk everyone
19:20:28 <mikeperry> #endmeeting *baf*