19:00:58 <mikeperry> #startmeeting
19:00:58 <MeetBot> Meeting started Mon Nov 24 19:00:58 2014 UTC.  The chair is mikeperry. Information about MeetBot at http://wiki.debian.org/MeetBot.
19:00:58 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
19:02:27 <mikeperry> ok, so let's get started
19:03:11 <mikeperry> last week I sent in our end-of-year report. We are still waiting to oficially finalize the contract for the next two years, but I think that is in good shape
19:03:56 <mikeperry> I also made some comments on HTTP/2 wrt website traffic fingerprinting
19:04:17 <mikeperry> there may be some last minute tweaks to that proposal that make it better for us for website traffic fingerprinting and privacy
19:04:49 <mikeperry> this week I guess is a short week for the US folks
19:05:19 <mikeperry> and apparently our next ESR dot release is due to arrive Dec 2
19:05:53 <mikeperry> as I see it, the plan for that is to backport the cache isolation fixes to 4.0, and then merge as much as we can that is ready for 4.5-alpha-2
19:06:08 <mikeperry> though that may be tight due to the US holiday
19:06:46 <GeKo> #13784 should get fixed too
19:07:08 <GeKo> it is another fallout from removing the safecache js code
19:07:34 <mikeperry> ah. hrmm
19:07:49 <GeKo> if we don't have the time then an easy thing is putting that part into JS back
19:08:00 <GeKo> until we create a proper C++ patch
19:08:03 <mikeperry> I wonder if I can fix that with another application of GetFirstPartyURI in the http auth code
19:08:31 <GeKo> might be the cleanest thing to do
19:12:32 <mikeperry> ok
19:13:03 <mikeperry> I am tagging all tickets in needs_review with TorBrowserTeam201411R
19:13:40 <mikeperry> for #13784, I gues for 4.0 the safest thing is to only backport the Firefox side of the patch
19:14:02 <mikeperry> which will fix the cache isolation independently of the need to remove safecache
19:14:19 <mikeperry> safecache will still try to isolate the cache, but fail. it should still succeed in stripping 3rd party auth
19:15:01 <GeKo> yes, sounds good to me
19:15:47 <mikeperry> 4.0 and 4.5 will have separate Torbutton versions anyway, because of the circuit UI and the slider
19:16:40 <mikeperry> I think I have noticed some oddities with the slider that I need to look into. It seems to not be telling Noscript to disable JS for non-HTTPS pages for the "Medium-High" setting
19:18:29 <GeKo> I planned to look at those myriad of https related NoScript prefs this week anyway
19:18:37 <mikeperry> anyway, that will require a ticket
19:18:41 <GeKo> so if you want I can investigate this
19:19:18 <mikeperry> ok
19:20:48 <mikeperry> oh, my submission to CCC for a talk on reproducible builds was accepted, so now I'm trying to do the wrngling to coordinate a joint talk with Lunar^ from debian, hans from guardian project, and possibly seth from EFF
19:20:58 <mikeperry> that's it for my ramblings. someone else should go next :)
19:22:37 <MarkSmith> mikeperry: did you intend to add keyword TorBrowserTeam2014R (not …201411R) to  #13671 and #13672?
19:23:41 <mikeperry> MarkSmith: no I did not. thanks for catching that
19:23:55 * MarkSmith can give a report.
19:24:01 <MarkSmith> Last week Kathy and I investigated #13776.
19:24:09 <MarkSmith> We finished and posted patches for #13379 (reviews requested).
19:24:21 <MarkSmith> We also helped with triage of some assorted TB bugs including #13788 and #13818,
19:24:29 <MarkSmith> we reviewed and commented on the end-of-year report that Mike wrote,
19:24:38 <MarkSmith> and we did some updater testing after 4.5-alpha-1 was released.
19:24:50 <MarkSmith> This week we will follow up on review comments for #13379,
19:24:59 <MarkSmith> we will work on other TB bugs including #13818
19:25:09 <MarkSmith> and we will enjoy a couple of days off in celebration of the U.S. Thanksgiving holiday.
19:25:14 <MarkSmith> That's all for now.
19:26:23 <GeKo> Here is what I did:
19:26:51 <GeKo> I helped with the 4.5-alpha release (answered blog questions; fixed the website)
19:27:01 <GeKo> tested #11630
19:27:35 <GeKo> investigated bugs related to the alpha (#13788, #13784, #13786)
19:28:15 <GeKo> then I spent quite some time reviewing the end-of-contract report
19:28:38 <GeKo> I included a bit of feedback for the security slider
19:29:17 <GeKo> and I walked to Mount Doom and came back with several keys which are hopefully fine now :)
19:29:33 <mikeperry> oh right I need to check those
19:29:47 <GeKo> I started a review for #13761 but am not done yet
19:29:57 <GeKo> err #13671
19:30:58 <GeKo> so, this week I plan to finish the review for #13671 get the slider in shape for the next alpha and look at the MAR signing bits #13379
19:31:21 <GeKo> I'd like to understand how the signing is working and maybe while I am at it I can create keys here too
19:31:30 <GeKo> I might bet empted to test it as well
19:31:40 <GeKo> that's it so far from mew
19:31:45 <GeKo> *me
19:31:57 <MarkSmith> GeKo: Let us know how we can help with MAR signing related stuff
19:32:07 <GeKo> will do
19:32:11 <MarkSmith> thx
19:33:07 <mikeperry> how hard will it be to change MAR keys?
19:33:46 <mikeperry> I suppose if people with an old key baked into the browser don't update to the version with the key switch, they won't be able to update to any later versions?
19:34:30 <mikeperry> can we include the support for MAR signing but pref it off? will the browser still be able to use signed MARs without verifying them?
19:35:55 <MarkSmith> We would need to provide MARs signed with the old key for people who have old browsers.
19:36:09 <MarkSmith> Currently, verification is not controlled by a pref.
19:36:49 <MarkSmith> If you compile without the --enable-verify-mar configure option,
19:37:16 <MarkSmith> the browser will not look at the signature block in the MAR at all (so no verify and no complaint if signed or not signed).
19:38:24 <MarkSmith> Allowing disable of verification via a pref sounds a little scary but could be done (social engineering possibilities).
19:38:37 <MarkSmith> "Turn off this pref to make the update work."
19:39:11 <GeKo> yes, indeed
19:40:48 <GeKo> screwing up with the keys should not happen very often, so I am inclined to say if this happens people need to download a new version
19:41:04 <GeKo> we need to write a blog post explaining things then anyway
19:41:31 <MarkSmith> Download a new version might be the best thing we can do for now.  I wonder if Mozilla ever ran into this?  Just keep using the same key ;)
19:41:45 <GeKo> ha
19:43:50 <mrphs> is this a good time to ask a random question about tbb?
19:44:52 <Syrup-tan> Probably #tor, there's a meeting atm, mrphs
19:45:24 <mikeperry> I guess it depends on if it's a question about TBB development/plans
19:45:48 <mrphs> im wondering how we are taking care of bookmarks in tbb.
19:46:37 <mrphs> onions are hard to remember, ppl bookmark them, i just thought it might be a juicy place to attack a client.
19:46:40 <mikeperry> as far as I know, bookmarks are always preserved, but history is only saved if you enable disk records
19:47:35 <mrphs> should we do something about it in future?
19:47:41 <mrphs> should we teach users not to use bookmarks?
19:49:38 <mikeperry> what is the attack vector?
19:50:26 <mikeperry> this seems like a long discussion with no good solution, btw.. it seems like it ends with "remove all bookmark support" or "only allow bookmarks if the user wants to store all history". Neither of which strike me as great solutions
19:50:37 <mikeperry> unless there is a specific type of leak we're worried about with bookmarks
19:50:55 <mikeperry> url bar key completion/search, perhaps?"
19:51:55 <mrphs> i havent put much thoughts about it, it just crossed my mind that having an onion address bookmarked, is enough evidence that you visited that url.
19:52:21 <mikeperry> ok. then this probably is not the best time to go down that rabit hole
19:53:02 <mrphs> fair enough
19:53:19 <mikeperry> if you think the url bar search is a bad feature to have because of accidental leaks, I could believe that and be confinced to disable it unles syou are storing disk records
19:54:22 <mikeperry> so perhaps think about the specific attacks/types of leaks you're worried about and either file a ticket, or discuss them later/next week
19:54:50 <GeKo> filing a ticket is a good plan
19:56:14 <mikeperry> ok, who wants to go next?
19:57:04 * arthuredelstein can go
19:57:21 <arthuredelstein> Last week I finished up my patch for #13671
19:58:03 <arthuredelstein> Since then I've been working on #13749.
19:58:50 <arthuredelstein> I'll hopefully be able post those patches early this week
19:59:21 <arthuredelstein> That's it for me
20:00:10 <Yawning> hi
20:00:25 <Yawning> is there anything in tor browser land that requires my attention beyond 2 patches I need to write
20:00:43 <GeKo> I don't think so.
20:01:02 <Yawning> as far as I can tell except for a random av false positive, obfs4proxy works great
20:01:12 <GeKo> \o/
20:01:19 <Yawning> and I like dcf's busybox style binary idea
20:01:36 <Yawning> though the compressed bundle saving isn't that much
20:01:49 <GeKo> not yet :)
20:02:14 <Yawning> well, with all our current/planned go binaries it saves a few hundred k?
20:02:26 <Yawning> because xz's window size is huge
20:02:59 <Yawning> it's a good chunk off the installed footprint so might be worth it anyway
20:04:00 <Yawning> y'all don't have objections to a tor-firewall-helper being in bundles right?
20:04:33 <Yawning> I'll probably integrate it as part of the pt build process (though it would be useful for the relay/expert bundle as well... hmm)
20:05:45 * boklm can go next
20:06:07 <boklm> This week I don't have much to report as I was mainly working on tor-messenger build
20:06:12 <boklm> Other than that I reviewed the build changes on #13379 and started some cleanup on tbb-testsuite scripts.
20:06:25 <boklm> That's all for now.
20:06:39 <MarkSmith> boklm: I saw your comments on #13379 and will respond.  Thanks for the review.
20:06:51 <mikeperry> the mac bundles appear to be growing faster than everything else.. perhaps because they use bzip2. I guess nsis might still use lzma for windows, windows seems to be still rather small
20:07:13 <boklm> MarkSmith: ok. Thanks.
20:07:30 <Yawning> well, we have a solution that lets us cut down the binary size, needs minor tweaks but could get it ready
20:08:26 <Yawning> #13770
20:08:32 <GeKo> boklm: what are the plans for tackling the spurious test failings?
20:08:59 <GeKo> like the resource timing one today and the fte tests?
20:10:53 <boklm> we try the tests 2 times when they fail, but it seems it is not enough for fte which fails often. maybe I can increase it for fte tests.
20:11:41 <boklm> I need to look at the resource-timing failure
20:11:51 <GeKo> oh and while I am it: what are our plans to get tests running on windows?
20:12:14 <GeKo> I have especially the compiler bugs in mind here
20:12:36 <GeKo> and it would be cool to avoid a release with such issues...
20:13:24 <GeKo> so I thought about writing a simple test which just loads "important" websites and if evrything is fine the test passes.
20:14:11 <boklm> I can move running the tests on windows to the top of my todo list
20:14:51 <GeKo> this should catch things like #13443
20:14:52 <boklm> the "loads important websites" test looks like a good idea
20:15:35 <boklm> I will check this week the status about running the tests on windows
20:15:43 <GeKo> thanks
20:15:49 <armadev> do we put linkedin on that list? :)
20:16:02 <armadev> (#10631)
20:17:47 <Yawning> for a while tor browser would flip out loading our timeline on trac
20:18:03 <boklm> I think we need to fix it first, before adding it to that list
20:18:12 <Yawning> (for "cpu pegged at 100% then the kernel kills it after a while" sort of flip out)
20:18:46 <armadev> boklm: makes sense
20:20:35 <Yawning> oh, hmm, it still happens :/
20:20:45 <mikeperry> sounds like an upstream bug that we might be making worse with all of our addon-based http handlers?
20:20:59 <mikeperry> I wonder if 4.5-alpha-1 is any better without safecache
20:21:21 <Yawning> well, I'm using 4.5 alpha-1
20:21:28 <mikeperry> still would have lots of observers elsewhere.. https-everywhere, noscript, and a couple more still in torbutton
20:22:10 <armadev> tjr: i'd ask you a question in #tor-project but you're not there. now i am stuck. :)
20:22:31 <Yawning> what causes tor-browser (firefox) to sit there mallocing like crazy in a tight loop?
20:22:37 <Yawning> till the oom killer kicks in
20:22:45 <Yawning> yawning  10935 24.7 83.6 14211504 13689304 pts/1 Rl+ 07:05 197:37 ./firefox --class Tor Browser -profile TorBrowser/Data/Browser/profile.default
20:22:54 <armadev> zowie
20:23:00 <Yawning> yawning  10935 24.8 91.7 15541680 15019036 pts/1 Rl+ 07:05 197:52 ./firefox --class Tor Browser -profile TorBrowser/Data/Browser/profile.default
20:23:04 <Yawning> etc
20:23:08 <GeKo> It seems I get again external-app-blovker related errors in my console
20:23:16 <GeKo> which sounds like #9001
20:23:25 <GeKo> no, not that one
20:23:37 <GeKo> #9901
20:24:13 <asn> tjr++
20:24:33 <GeKo> might be related, dunno
20:25:09 <Yawning> *looks*
20:26:49 <Yawning> is this an only me thing?
20:27:12 <GeKo> I don't have the timeline problem
20:27:37 <Yawning> I go to the timeline, click the "show all the things box" and hit update
20:27:45 <Yawning> hmm happens with vanilla ff too
20:28:40 <Yawning> the ticket updates display
20:29:03 <GeKo> ah, yes, I see it too now, interesting
20:30:20 <Yawning> since it happens with vanilla ff I assume it's not us
20:30:40 <Yawning> (33.1.1)
20:30:50 <MarkSmith> I also see the timeline hang on Mac OS with vanilla Firefox (34 beta for what that's worth).  Need to go kill it now as it is sucking up all my system RAM.
20:30:58 <Yawning> yup
20:31:19 <Yawning> it keeps on chewing up ram in a tight loop till malloc starts failing or the oom killer kicks in
20:32:24 <Yawning> did our trac become evil all of a sudden?
20:35:13 <asn> bridge-ip-versions v4=16864,v6=0
20:35:13 <asn> bridge-ip-transports <OR>=8,fte=8,obfs2=8,obfs3=16568,obfs4=72,scramblesuit=216
20:35:19 <asn> got them all!
20:35:38 <asn> wow new TBB, such PTs,
20:35:44 <kernelcorn> what part of Tor's source determines the middle nodes? Is there a specific file?
20:36:13 <asn> kernelcorn: see circuit_establish_circuit()
20:36:15 <mikeperry> ok, is there anything left in TBB land?
20:36:25 <mikeperry> for today's meeting?
20:36:45 <kernelcorn> thanks asn
20:36:56 <asn> kernelcorn: see choose_good_middle_server() in onion_extend_cpath()
20:37:43 <mikeperry> ok. I am going to call it then
20:37:48 <mikeperry> #endmeeting *baf*