18:01:31 <GeKo> #startmeeting tor-browser
18:01:31 <MeetBot> Meeting started Mon Aug 15 18:01:31 2016 UTC.  The chair is GeKo. Information about MeetBot at http://wiki.debian.org/MeetBot.
18:01:31 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
18:01:41 <GeKo> hi all and welcome to another meeting.
18:02:08 <GeKo> who wants to go first today?
18:03:47 * mcs can give a report
18:04:04 <mcs> Last week, Kathy and I developed patches for #17858, #19336, and #19906.
18:04:11 <mcs> We also worked on #19733 (we posted a patch for that bug earlier today).
18:04:17 <mcs> We started on #15852 but still have some more work to do.
18:04:24 <mcs> This week we plan continue with #15852 and then start working on #14271 and/or #14272.
18:04:33 <mcs> We may also look at #19646 again since that is a TB 6.0 regression for which we are responsible.
18:04:37 <mcs> That’s all for now.
18:04:58 <mcs> Oh, and thanks to GeKo for reviewing and merging things.
18:05:25 <GeKo> those were the more joyful things for me this week :)
18:05:34 <mcs> :)
18:06:05 <GeKo> okay, here is what i did:
18:06:20 <GeKo> i spents some time looking at #19856 and #19857
18:06:46 <GeKo> the most time i was busy wwith dealing with #19890 which is quite nasty
18:07:07 <GeKo> i prepared 6.0.4 and hope to get it our tomorrow
18:07:40 <GeKo> it will basically contain the new stable tor and a fix for that bug on our side (mozilla helped a lot with the server side)
18:08:24 <GeKo> i worked on the design doc and sponsorU items regarding to the iSEC report
18:08:35 <GeKo> #19920 is one of the results
18:09:07 <GeKo> i prepared the release notes for 6.0.4 https://blog.torproject.org/blog/tor-browser-604-released
18:09:15 <GeKo> and wold appreciate comments/changes if needed
18:09:46 <GeKo> finally i managed to get rid of my backlog, triaged tickets and looked over the blog comments
18:10:06 <GeKo> this week i hope 6.0.4 gets out and things start to slow down a bit again
18:10:47 <GeKo> i plan to get work done on the design document and remaining iSEC related sponsorU items.
18:10:55 <GeKo> that's it.
18:11:38 <mcs> The 6.0.4 announcement looks OK to me.
18:12:40 <GeKo> thanks.
18:13:34 <arthuredelstein> Looks good to me as well.
18:13:54 * arthuredelstein can go
18:14:03 <arthuredelstein> Last week again I was largely afk.
18:14:22 <arthuredelstein> But in my limited time I focused on #13018 and #13017.
18:14:52 <arthuredelstein> I have confirmed what boklm saw, that libm can be used to mitigate both issues.
18:14:59 <GeKo> neat
18:15:15 <arthuredelstein> And I nearly have a patch that integrates libm, but it's kinda a rabbit hole.
18:16:11 <arthuredelstein> One option I think might work better is to include libm and similar libraries once we have containerized TBB.
18:16:35 <arthuredelstein> But I'm hoping at least to have a prototype patch soon that we can test.
18:16:57 <arthuredelstein> I also did some review of patches being uplifted to Mozilla.
18:17:38 <arthuredelstein> This week I will be back to work, and I plan to do more such reviews, and look more at porting the resizing patch to the browser.
18:17:41 <arthuredelstein> That's it for me.
18:18:43 <GeKo> which mozilla patches did you look at? there seems to be much work going on right now
18:18:58 <GeKo> (at least according to my bugzilla spam)
18:19:21 <GeKo> could you have a second look at #19706 as well?
18:19:38 <arthuredelstein> Yes, mainly the isolation regression test framework patch
18:19:51 <GeKo> okay.
18:20:22 <arthuredelstein> bugzil.la/1281319
18:20:44 <arthuredelstein> Sure, I'll give #19706 a look
18:22:09 <GeKo> ah, you meant 1289319, okay.
18:22:18 <GeKo> whe else is here?
18:22:38 <arthuredelstein> oops, you're right
18:22:41 <GeKo> boklm is on vacation but maybe others are at the meeting for questions, updates etc.
18:23:59 <GeKo> okay, i have one item on my discussio list
18:24:16 <GeKo> with the help of a user i looked at #19907 last week
18:24:29 <GeKo> and all we found was that the extension was okay
18:24:54 <GeKo> and that after copying it over manually again everything worked as expected.
18:25:16 <GeKo> this seems to leave a bug during the signature verification which we don't touch
18:25:39 <GeKo> i asked in mozilla's #security if they had similar reports but got no answer
18:26:03 <GeKo> i wonder what we should do at this stage.
18:26:28 <GeKo> i guess i can start looking at changesets on gecko-dev and see whether they fixed things meanwhile
18:26:37 <GeKo> and try to find related bugs
18:26:50 <GeKo> + file one in Mozilla's bug tracker
18:27:05 <GeKo> but this things makes me pretty nervous in general
18:27:08 <mcs> We don’t really have steps to reproduce, or do we?
18:27:09 <GeKo> *thing
18:27:10 <arthuredelstein> Is there a way we could repeatedly trigger the signature check and try to see the rare failure?
18:27:22 <GeKo> mcs: no we don't
18:27:41 <GeKo> good question. i don't know.
18:28:07 <arthuredelstein> Were both reports on the same platform?
18:29:32 <GeKo> let me look.
18:30:42 <GeKo> one on ubuntu the other on windows 8
18:31:49 <GeKo> i am wondering whether we should disable this verification until those things get investigated and fixed.
18:32:41 <mcs> It might make sense to disable the checks. We could also try to reproduce it by repeatedly triggering the sig check (as Arthur suggested).
18:32:52 <mcs> You know that the xpi was good?
18:33:14 <GeKo> yes. i got it uploaded and the hash was the expected one
18:33:54 <GeKo> okay, this is something to mull over i guess for the next regular release at least.
18:34:20 <GeKo> help (with smart ideas etc.) would be appreciated :)
18:34:37 <GeKo> anything else up for discussion?
18:35:06 <arthuredelstein> GeKo: Did you get the error message (for #19907)?
18:35:27 <arthuredelstein> Would maybe be helpful to work out the code path.
18:35:34 <GeKo> no, alas not. i tried hard on different systems but failed so far :(
18:35:50 <GeKo> yes.
18:36:56 <mcs> I wonder how often sigs are checked.
18:37:14 <GeKo> it seems only on install
18:37:25 <GeKo> which would be another thing to look at
18:37:44 <GeKo> maybe we could trigger checking it every time.
18:37:57 <GeKo> maybe it is already that way (would make more sense i guess)
18:38:13 <GeKo> but then the noscript failure would be weird.
18:38:27 <GeKo> and i did not see anything in the debug log in this regard from the user
18:39:27 <GeKo> we managed to copy the malfunctioning tor browser and enable "extensions.logging.enabled" and no rechecking was visible
18:39:44 <mcs> It seems like a lot of Firefox users would be affected (just based on the odds of someone running into even a rare bug). Unless the bug only occurs in Tor Browser.
18:40:30 <GeKo> that is a good point. on the other hand maybe it is PBM related or due to some other non-vanilla thing we do
18:40:30 <Yawning> (Is this a good time for me to ask if I need to do more with the content policy stuff)
18:40:40 <GeKo> yes
18:40:50 <Yawning> "Do I need to do more with the content policy stuff"
18:40:53 <Yawning> ?
18:41:12 <GeKo> i've been thinking about that and came up with two options:
18:41:26 <GeKo> 1) back out your patches and declare defeat so far
18:41:44 <GeKo> 2) whitelist the urls and try to find out what else breaks
18:42:04 <Yawning> I have a branch that whitelists stuff
18:42:08 <Yawning> that's not public
18:42:09 <GeKo> i am not sure yet how promising 2) is
18:42:19 <Yawning> it fixed everything that people complained about
18:42:28 <Yawning> dunno
18:42:46 <Yawning> being able to slurp preferences etc via resource:// is really bad
18:42:52 <Yawning> so I'd opt for 2
18:43:01 <arthuredelstein> We could blacklist preference files instead I suppose
18:43:05 <Yawning> even if it's imperfect (evil can slurp the whitelisted urls)
18:43:51 <Yawning> arthuredelstein: that screws people that bolt on non-standard addons
18:43:59 <Yawning> among other things
18:44:07 <GeKo> arthuredelstein: maybe!
18:44:13 <arthuredelstein> Yawning: true
18:44:52 <arthuredelstein> So maybe a big whitelist that covers all harmless URLs is best?
18:45:02 <Yawning> so basically the lsit I posted?
18:45:13 <Yawning> I don't think we change any of those files
18:45:25 <Yawning> but by virtue of the whtielist existing people can tell taht the browser is tor browsr
18:45:37 <arthuredelstein> Yes, does that cover all the chrome/resource URLs?
18:45:40 <Yawning> and if upstream changes stuff inbetween versions, it leaks versioning (probably ok?)
18:45:52 <GeKo> yes
18:45:53 <Yawning> it covers all of the ones that people have reported as breaking
18:46:08 <GeKo> i suspect the chances of version leaking are not that big
18:46:11 <arthuredelstein> We don't hide that the browser is Tor Browser anyway
18:46:19 <GeKo> and that
18:46:29 <arthuredelstein> Also versions are probably also impossible to hide from a determined adversary
18:46:43 <arthuredelstein> Unless we never make improvements ;)
18:46:46 <Yawning> so
18:46:49 <GeKo> so, yes, 2) might be a think to consider for the next alpha
18:46:51 <Yawning> my suggestion
18:46:52 <GeKo> *thing
18:46:58 <Yawning> I publish my branch
18:47:03 <Yawning> that fixes the known stuff that breaks
18:47:06 <Yawning> we mrege that
18:47:15 <Yawning> and see what else if anything breaks horribly
18:47:26 <GeKo> yes, sounds good to me
18:47:35 <arthuredelstein> rome URLs to whitelist
18:47:46 <arthuredelstein> er, let me try again.
18:47:58 <arthuredelstein> I was thinking we could maybe add all chrome URLs to whitelist, except dangerous ones.
18:48:08 <arthuredelstein> So we don't have to wait for something to break.
18:49:25 <GeKo> hm. i have not looked but it seems to like this is quite some effort + resource:/// things
18:49:38 <GeKo> (determining the dangerousness)
18:50:02 <GeKo> s/seems to/seems/
18:50:07 <Yawning> hm
18:50:09 <Yawning> but
18:50:14 <Yawning> firefox loads both resource and chrome urls
18:50:18 <Yawning> for certain things
18:50:21 <Yawning> it's stupid as hell
18:51:04 <arthuredelstein> I should have said chrome and resource URLs.
18:51:22 <Yawning> I put a list in trac?
18:51:25 <arthuredelstein> I was more or less assuming only the pref files are dangerous
18:51:32 <GeKo> aha!
18:51:37 <arthuredelstein> And addons, too.
18:52:05 <GeKo> but i bet there are platform specific versions of some resource and chrome urls available
18:52:10 <Yawning> https://git.schwanenlied.me/yawning/torbutton/commit/4405f2cda9e39e3425ba4c027c933e07b7098bb2
18:52:17 <Yawning> oh derp
18:52:23 <arthuredelstein> True, I guess it's a case of whether we are trying to hide the platform.
18:52:24 <Yawning> I need to remove a dump()
18:52:39 <arthuredelstein> So far I have tended to assume we aren't as it is nearly impossible anyway.
18:52:56 <GeKo> right
18:53:38 <Yawning> *force pushes*
18:53:45 <arthuredelstein> Anyhow, I'm also OK with the "see what breaks" approach, as probably little is broken.
18:53:55 <Yawning> https://git.schwanenlied.me/yawning/torbutton/commit/eb7ad18e69e629e1229fe78a71b2f58e651fdf62
18:54:02 <Yawning> something like that
18:54:11 <Yawning> has fixed everything I am awayre of that's broken
18:54:49 <Yawning> it matches by URL and load type
18:55:12 <GeKo> cool. we can think about this some more but i guess taking your patch for the next alpha seems like a good idea.
18:55:25 <GeKo> thanks for doing that, yawning
18:55:33 <Yawning> I've had that sitting around
18:55:38 <Yawning> since the day the bug was reported
18:55:39 <Yawning> >.>
18:55:42 <GeKo> i can feel your pain fwiw :)
18:55:43 <mcs> Do we want to place it behind a pref so people can disable it if something breaks?
18:56:02 <mcs> (I think Yawning mentioned that idea in the code or ticket)
18:56:06 <Yawning> Dunno how people want to handle
18:56:16 <Yawning> gaping fingerprinting attacks
18:56:18 <GeKo> i tend to say, "no"
18:56:19 <Yawning> vs stuff breaking
18:56:35 <mcs> OK. We can just deal with problems if they come up then
18:56:43 <Yawning> could tie the whitelist to the slider so the extra paranoid can deal with broken stuff
18:56:48 <GeKo> this is alpha quality and the pref makes it so that if we need to test more those users are note exposed to the feature anymore
18:57:20 <arthuredelstein> We know for sure that the pref files should be blacklisted in any case.
18:57:31 <arthuredelstein> So we don't want to offer a pref to whitelist that part.
18:57:51 <GeKo> *not exposed
18:58:13 <Yawning> was thinking like "enable the pref to break the video player, because if you trust the codec to not be full of holes, you're kind of nuts"
18:58:32 <Yawning> but people will prolly complain
18:58:45 <Yawning> commented on trac with the branch
18:58:48 <GeKo> they did :)
18:59:08 <GeKo> okay, let's wrap up. anything else for today?
18:59:57 <GeKo> thanks for the meeting then, *baf*
19:00:00 <GeKo> #endmeeting