17:59:29 <GeKo> #startmeeting tor-browser
17:59:29 <MeetBot> Meeting started Mon Apr 18 17:59:29 2016 UTC.  The chair is GeKo. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:59:29 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
17:59:41 <GeKo> hi everyone!
18:00:05 <GeKo> i guess we start with the usual status updates. who wnats to go first today?
18:00:12 <GeKo> *wants even
18:00:47 <GeKo> i can start this time i guess
18:01:13 <GeKo> this week i worked on the OS X signing and it seems our code-signing is working now
18:01:36 <GeKo> #18820 is left and i currently have no clue how to solve that efficiently
18:01:48 <GeKo> ideas are very welcome!
18:02:12 <GeKo> there is one caveat: timestamping is not working as our signing box is locked down
18:02:31 <GeKo> this was already a pain in the ass wrt the windows bundles
18:02:43 <GeKo> but i guess this time it will even be more fun to get right
18:03:11 <GeKo> but this is no blocker for now; definitely not for the alphas
18:03:36 <GeKo> then i worked on getting our esr45 branch into shape: tor-browser-45.0.2esr-6.x-1 should be it
18:03:59 <GeKo> thanks for everybody who has been helping with #15197 and friends
18:04:06 <GeKo> *thanks to
18:04:27 <GeKo> then i worked a bit on the OTF proposal and had to deal with bug bounty stuff
18:05:07 <GeKo> i finished #13419 and #14970
18:05:33 <GeKo> the former is actually closing two affected bugs as well, so, yay!
18:05:53 <GeKo> and finally, i worked on the network audit issues
18:06:23 <GeKo> this week i'll continue to address all remaining issues there and do reviews + prepare releases i guess
18:06:33 <GeKo> that's it for now
18:07:15 * mcs will go next
18:07:24 <mcs> Last week, Kathy and I filed tickets for the “stuff we should fix” items from #18546.
18:07:32 <mcs> We worked on all of them (#18799, #18800, #18801, #18802).
18:07:42 <mcs> #18800 still has status “Needs Information” but the other tickets are closed.
18:07:49 <mcs> For #18800, we will probably just proceed and develop a patch that always uses 127.0.0.1 for the IP address (feedback is welcome).
18:07:56 <mcs> We also rebased the patch for #18777 last week.
18:08:00 <mcs> Last but not least, we reviewed a bunch of ESR45 fixes.
18:08:06 <mcs> This week we will create a patch for #18800 and we will work on other ESR45 issues.
18:08:11 <mcs> For example, we could start looking at #16673 if no one else is working on it.
18:08:17 <mcs> That’s all for us.
18:08:32 <GeKo> looking at that one would be helpful, yes
18:08:37 <mcs> OK
18:08:54 <GeKo> might be hard to get it isolated in time
18:09:13 <GeKo> so, we probably have to go the disabling road for now. but who knows :)
18:09:47 <arthuredelstein> I just posted a disabling patch for #16673 because it was very simple
18:10:06 <mcs> Ah, that’s good.
18:10:24 <mcs> Is isolation going to be really hard or is it an unknown?
18:10:47 <arthuredelstein> I haven't looked at the implementation yet.
18:10:51 <mcs> (and maybe there are other things Kathy and I should work on this week instead)
18:10:52 <mcs> OK
18:11:17 <mcs> GeKo: Feel free to adjust our priorities as needed.
18:12:01 <GeKo> ok. tbb-6.0a5 looks not that bad. i guess feel free to look at the stuff taht you think is most severe and tagged with ff45-esr
18:12:06 <mikeperry> I think alt-svcs only makes sense if we're going to enable all of http/2. and making sure the features that are enabled are safe and working properly probably takes higher priority.
18:12:18 <GeKo> like stuff you want to see geeting an alpha testing exposure
18:12:33 <mcs> GeKo: Sounds good.
18:12:44 <GeKo> *getting even
18:13:19 <GeKo> mikeperry: good point
18:15:15 * amoghbl1 wonders if he can go next
18:15:24 * arthuredelstein will go after amoghbl1
18:15:47 <amoghbl1> OK, so as of last week, we got down a stable build of Orfox
18:16:16 <amoghbl1> n8fr8 is working on the security patches related to that that were brought up with the thread with the mozilla folk
18:16:56 <amoghbl1> Based on which ones he sees required for the present update we have scheduled, he will work on those and get something out quick
18:17:28 <amoghbl1> As for ESR45, I think we are going to have to wait until all the tbb patches land to work on it
18:18:21 <mikeperry> amoghbl1: when you get to ESR45 (we should have an alpha out for it in the next week), you should keep an eye on #18546 FYI. there are some things there that may affect android. I will be updating it with more stuff this week, but all the remaining stuff is cross-platform (and low risk)
18:18:53 <GeKo> i think you can start with tor-browser-45.0.2esr-6.x-1 for testing purposes
18:19:36 <GeKo> we might add some android related patches coming from #18546 but the vast majority of our patches is already there
18:20:05 <amoghbl1> thanks for the pointer mikeperry.
18:20:22 <amoghbl1> And yes, I will be able to start testing once tor-browser-45.0.2esr-6.x-1 is out
18:21:01 <amoghbl1> I've mentioned a rebase work section in my GSoC proposal, but looks like we got that down last week, so I could use that time to work on things related to esr45
18:21:25 <amoghbl1> That's it from me!
18:23:24 * arthuredelstein can go now
18:23:29 <arthuredelstein> Last week I worked on finishing up patches for #15197.
18:23:38 <arthuredelstein> And I did some work on #18741.
18:23:50 <arthuredelstein> It seems that there is some apparently redundant favicon code that I can comment out to get rid of the problem, but I'm trying to understand it more deeply.
18:24:12 <arthuredelstein> I also worked on #16998 and #16326. I hope to post patches for these later this week.
18:24:38 <GeKo> do we need something for #16326?
18:24:50 <GeKo> or are we lucky here with the existing stuff we have?
18:25:09 <arthuredelstein> It seems to be OK but I want to have a patch for our caching regression test.
18:25:22 <GeKo> ok
18:26:55 <arthuredelstein> So this week I'll try to finish up those patches and if there is any more time, I'll take on any other needed tbb-6.0a5 ticket.
18:26:58 <arthuredelstein> That's it for me
18:27:56 <mikeperry> for the OTF proposal, do we have a clear set of options for more secure updater work? I am reluctant to list it given the somewhat uncertain state of getting Prop@227 into Tor and reliably performed by dirauth operators. That doesn't mean we can't do it, it just means it's risky to list as a deliverable
18:28:09 <mikeperry> prop#227, even
18:29:39 <mikeperry> oh, I guess it was implemented in tor-core. mised that :). still it will need scripts/plumbing/coordination with dirauth operators, and some tricky logic for deciding what to do if there are byzantine failures causing omissions of the hash url, etc
18:30:33 <mikeperry> I could easily see a long and annoying "experimental" phase for such a thing. and if dir-auths decide to riot about the scripts being too sketchy or too much work or whatever, we'd be in trouble
18:30:45 <GeKo> yes, we could think about #13730 or #17216
18:30:50 <mikeperry> do we have alternatives for it?
18:30:59 <mikeperry> ah, ok
18:31:09 <GeKo> and i thought we should evaluate the things mentioned in leif's piece
18:31:56 <GeKo> so, my idea was having a throught analysis phase where we put all the ideas floating around on the table
18:32:20 <GeKo> and then we pick one that seems best to us at the moment and get that done
18:33:24 <GeKo> *thorough
18:33:25 <mcs> Being smart about our options seems like a good idea.
18:33:59 <mcs> We want to make sure we add value rather than make the updater less reliable somehow
18:34:06 <mcs> (so secure it doesn’t work?)
18:34:40 <GeKo> exactly. there are a bunch of ideas available where i'd like exactly against which threats they are helping
18:35:02 <GeKo> bah, *to know exactly
18:35:10 <mikeperry> we may be transitioning to a CDN for the packages themselves, so even that may require some security consideration
18:35:18 <GeKo> indeed
18:35:33 <mikeperry> for example, the pings to get the new files + hashes should probably not come from that CDN, but a hiddenservice or separate pinned HTTPS cert
18:35:49 <mcs> There are also some implementation tradeoffs because whatever we do will probably involve additional core browser patches.
18:36:01 <mikeperry> so, ok. work will definitiely happen there anyway
18:36:10 <GeKo> yes
18:37:45 * boklm will give an update next
18:37:58 <boklm> This past week I finished converting all Mozmill tests to Marionette (#16009)
18:37:59 <boklm> This week I'm planning to work on #17895, #18597, #18845
18:38:10 <boklm> I will also look at #18820 to see if I have some ideas on how to solve this
18:38:21 <boklm> That's it for me.
18:39:21 <GeKo> re #17895: just getting nsis cross-compiled and used for our bundles would be enough for the alpha i think
18:39:34 <boklm> ok
18:39:40 <GeKo> we can test the other stuff during build (hehe) and in the coming weeks
18:40:03 <GeKo> and thanks for stepping up
18:40:21 <GeKo> i should have delegated that one earlier i guess :(
18:40:49 <GeKo> it almost dropped from my radar but coderman came to the rescue
18:42:59 <GeKo> so, who is left? mikeperry?
18:43:03 <mikeperry> ok, so this OTF proposal has a soft submission date of Wednesday. I am hoping to get everything on the TBB side in shape for GeKo by then, but both isabela and I are occupied with other stuff this week, so we probably will need the extra time. I am thinking we should circulate it among the team first, if we can, also, but time pressure may prevent that
18:45:47 <mikeperry> other than that, I will be finishing the Firefox networking review. but like I said, the remaining stuff is all just the XPCOM usage of networking functions. low-risk. mostly only addons use that stuff
18:47:14 <GeKo> okay. is anyone else here for status updates? do we have discussion topics today? questions?
18:49:39 <GeKo> thanks everybody *baf*
18:49:43 <GeKo> #endmeeting