17:31:19 <GeKo> #startmeeting tor browser 5/6
17:31:19 <MeetBot> Meeting started Mon May  6 17:31:19 2019 UTC.  The chair is GeKo. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:31:19 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
17:31:23 <pili> hi
17:31:49 <GeKo> let's get started
17:31:56 <GeKo> i hope you all had a good week
17:31:56 <boklm> hi
17:32:07 <GeKo> it got quite rough at the end, though :)
17:32:14 <GeKo> anyway
17:32:19 <GeKo> please update the items on the  pad
17:32:28 <GeKo> https://storm.torproject.org/shared/tHoN4Ii7rLSjPE0OP4gydX4cMGadsXmRQNc-6lwru0N
17:32:36 <GeKo> and check your mail
17:32:49 <GeKo> i sent one which could be relevant for our esr68 transition
17:33:53 <GeKo> sysrqb: are you with us today?
17:35:06 * boklm doesn't see an email about esr68 transition. How long ago was it sent?
17:35:48 <sisbell> hi
17:36:14 <GeKo> boklm: it was about igor
17:36:24 <sysrqb> o/
17:36:39 <GeKo> boklm: shoot i forget to add you :(
17:36:39 <sysrqb> sorry, lost track of time :)
17:36:44 <GeKo> let me forward it
17:36:51 <GeKo> sorry for that
17:36:54 <boklm> thanks
17:37:37 <GeKo> sent
17:38:38 <GeKo> okay, let#s get started
17:38:48 * pili thinks we need a browser-team email list :)
17:38:51 <GeKo> it seems none of the updates contain anything bold
17:38:56 <GeKo> nah, just for that one mail
17:39:49 <GeKo> assuming sysrqb does not have anything bold in status updates
17:40:02 <GeKo> lets move on dicussion
17:40:35 <GeKo> mcs: you are first
17:41:39 <mcs> Probably not something we can figure out today, but we should think about how to ensure that bundled extensions can never be blocked… even by accident. Unless we view that capability as a feature.
17:42:02 <mcs> It is tricky because we allow updates of the extensions.
17:42:59 <GeKo> yeah. the solution i had in mind was rolling out our own PKI, but i am not sure anymore *cough*
17:43:07 <mcs> :)
17:43:20 <GeKo> but i agree
17:44:05 <acat> have we considered bundling the critical extensions as system addons?
17:44:06 <mcs> I guess at some point we will need a proposal… maybe a brainstorming meeting before that would make sense.
17:44:13 <GeKo> to be honest i never thought it possible that mozilla would forget the expiration date of the intermediate cert, so i did not spend much thougt about that
17:44:41 <pili> mcs: is it too much/too soon for a dev meeting session?
17:44:52 <GeKo> acat: how would they get updates
17:44:53 <GeKo> ?
17:45:12 <mcs> pili: I would say having a session would be appropriate.
17:45:27 <pili> great :)
17:45:30 <acat> I'm not sure, here https://firefox-source-docs.mozilla.org/toolkit/mozapps/extensions/addon-manager/SystemAddons.html it says that balrog
17:46:39 <acat> not sure if armagadd-on 2.0 would still have been an issue in that case
17:48:26 <sysrqb> one way of avoiding this, in part, is integrating more of the core extensinos into the browser
17:48:43 <sysrqb> i think some of that has been discussed in the past
17:48:56 <pospeselr> what about going a step further and integrating the needed functionality into the brwoser itself like we're doing bit by bit with torbutton et al?
17:49:06 <GeKo> acat: interesting
17:49:14 <pospeselr> um yeah what sysrqb said
17:49:21 <sysrqb> :)
17:49:35 <sysrqb> ideally, mozilla would do this
17:49:37 <mcs> Based on the page acat mentioned, it sounds like there is a separate signing certificate for system add-ons.
17:49:44 <sysrqb> similar with their tracker protetion work
17:50:29 <boklm> a separate certificate that can expire too?
17:50:35 <mcs> boklm: yes
17:50:37 <mcs> :)
17:50:55 <boklm> although now that they made this mistake, they will probably monitor expiration of those certificates more carefully
17:51:02 <brade> sysrqb: so Mozilla would build “no script” and “https everywhere” into the browser?
17:51:03 <pospeselr> controlling our cert exper date seems to be an important feature of late :p
17:51:15 <antonela> :)
17:51:18 <sysrqb> brade: essentially, yes
17:51:43 <antonela> building extensions with the browser breaks the nature of the extensions ecosystem
17:51:46 <sysrqb> or integrate the functionality, and let (for example) https-everywhere maintain the ruleset
17:52:15 <sysrqb> like mozilla use the disconnectme lists
17:53:10 <sysrqb> antonela: this is true, except these are our core extensions, so they're not really "extensions" anymore for us
17:53:25 <pospeselr> yeah exactly
17:53:25 <sysrqb> just like tracking protection isn't an extenion in firefox anymore
17:53:28 <antonela> yeah, for us is interesting, i doubt about firefox
17:53:33 <antonela> yes exactly
17:53:36 <sysrqb> (although, you can add more tracking protection via extrensions is you want)
17:54:01 <sysrqb> maybe they should be part of mozilla's core browser, too :)
17:54:06 <GeKo> okay, it seems we have a bunch of ideas
17:54:11 <sysrqb> heh
17:54:14 <antonela> are we going to build our own security protection? :)
17:54:33 <GeKo> worth a seesion at the dev meeting as others pointed out
17:54:51 <pili> I've added it to my list of sessions :)
17:54:58 <GeKo> i guess we should come up there with an idea on  how to move forward
17:54:59 <GeKo> thx
17:55:28 <GeKo> 8.5 release work
17:55:46 <GeKo> i had hoped to have some release candidate for 8.5 by now
17:56:24 <GeKo> but i am not super sad that we did not get to get this going
17:56:40 <GeKo> we wouldn't have release 8.5 this week anyeay
17:56:43 <GeKo> *released
17:56:48 <GeKo> *anyway
17:57:11 <GeKo> that said i am not sure anymore whether we should ship it with the point fix next week
17:57:22 <GeKo> given that we don't even have 8.0.9 out yet
17:57:56 <GeKo> what's the feeling here of postponing 8.5 yet another week?
17:58:31 <GeKo> so we have enough time to test release-y issues without the clock ticking for the sec update
17:58:44 <pospeselr> sounds reasonable to me
17:59:09 <antonela> that will allow us sysrqb to sync about #29955
17:59:32 <GeKo> yes, although this is no blocker for 8.5
17:59:43 <GeKo> i mean it can get done once 8.5 is out e.g.
17:59:49 <GeKo> or while it is built
18:00:22 <GeKo> but if that helps to get a better orfox transition then this is certainly a plus
18:00:47 <antonela> oh are tbb-8.5-must the blockers?
18:01:32 <GeKo> they were meant to be originally
18:01:44 <antonela> oki, thanks
18:02:00 <intrigeri> my 2cts: for Tails, switching to 8.5 next week is a bit more relaxing: we do that for a scheduled release instead of potentially having to do the switch in a bonus chemspill release later in May-June. But given 8.5 seems to change very little for us, it's just 2cts.
18:02:43 <GeKo> okay
18:03:42 <GeKo> hearing no objections we'll try to get the armagadd-on 2.0 out
18:03:54 <GeKo> and then start immediately building for the esr60.7.0 release
18:04:00 <GeKo> and once that is out
18:04:06 <GeKo> we finally start building 8.5
18:04:26 <GeKo> and meanwhile we try to cut down all the rough edges for mobile on 8.5 :)
18:04:39 <GeKo> does that sound like a workable plan?
18:04:47 <boklm> yes
18:04:52 <pospeselr> yeah
18:04:52 <sisbell> sounds good
18:05:34 <sysrqb> yeah. i was hoping we'd release 8.5 sooner, but this plan seems like a good idea (safer plan)
18:06:48 <GeKo> okay, then let's do that and move to the esr68 transition item
18:07:07 <GeKo> we got started here last week already
18:07:09 * mcs quietly added #29627 to mcs/brade work items for this week
18:07:24 <GeKo> mcs: oh, that one
18:07:39 <GeKo> it might be a spec bug, dunno, i have not checked
18:08:09 <mcs> I am not sure either; I know we thought about it when we wrote the code but I will need to refresh my memory.
18:08:12 <GeKo> or i was just dumb (in that case just reset the state := =
18:08:16 <GeKo> err
18:08:17 <GeKo> :)
18:08:34 <GeKo> okay, esr68 transition
18:08:53 <GeKo> we seemed to agree we should start as soon as possible to put more resources on that part
18:09:24 <GeKo> the fact that we have one member less for the transition work just makes this more urgent
18:09:47 <GeKo> moreover we have other sponsor work (s27) we have to balance
18:10:22 <GeKo> and there will be other issues showing up that will make esr68 the morest exciting transition ever
18:11:37 <GeKo> thetwo most important items we should start with is rebasing our patches
18:11:59 <GeKo> (and ideally trying to sneak some of thos still into mozilla so they make it into esr68)
18:12:23 <GeKo> pospeselr: once you are done with the widl bug could you worko n that with acat?
18:12:32 <pospeselr> yeah!
18:12:50 <GeKo> sysrqb: could you do the mobile patch part?
18:12:59 <sysrqb> yes
18:13:00 <GeKo> mcs: brade: and you the updater onces?
18:13:04 <GeKo> *ones
18:13:16 <mcs> GeKo: yes
18:13:21 <GeKo> okay.
18:13:34 <GeKo> i'll create the ticket for that
18:13:56 <GeKo> and i think as soon as esr68 hits beta we should get this going
18:14:13 <GeKo> in parallel i'll start working on the toolchains
18:14:32 <GeKo> (in fact  i already started earlier on p orting tjr's mingw-w64/clang work)
18:14:48 <GeKo> and boklm will join me once #28672 is done
18:15:06 <GeKo> sisbell: you would take care of the android one?
18:15:44 <sisbell> GeKo: which one?
18:16:00 <GeKo> prepring the android toolchain for esr568
18:16:03 <GeKo> huh
18:16:06 <GeKo> esr68
18:16:12 <sisbell> Sure, I'll do that
18:16:21 <GeKo> aka #30324
18:16:47 <GeKo> sisbell: i think that's the most important work after 8.5 gets out
18:17:04 <GeKo> we should have somethign ready early on even if not all patches are rebased yet
18:17:16 <GeKo> okay
18:17:55 <GeKo> so, to be explicit: what this means is we need to either work on sponsor work (like s27)
18:18:02 <GeKo> or getting 8.5 out
18:18:19 <GeKo> or on esr68 transition tasks
18:18:29 <GeKo> all other things need to get dropped right now
18:19:01 <GeKo> antonela: i think that means the per-site security settings for now
18:19:19 <GeKo> if we have enough time i am happy to add that work back on the agenda
18:19:21 <antonela> perfect
18:19:28 <GeKo> but right now it does not look very good :(
18:19:50 <antonela> :/
18:20:02 <GeKo> any questions? comments? ideas?
18:21:11 <GeKo> okay, we can come back to that later on
18:21:14 <GeKo> like next week
18:21:19 <brade> Who’s creating the esr68 git branch?
18:21:32 <pili> that's fine with me, only one comment that at some point we'll need to start looking to S9 phase 3 and get things like nightly build working :)
18:21:42 <pili> but that will be for September
18:21:54 <GeKo> the nightly build updater
18:22:14 <pili> (we can maybe also look at the per site security settings as part of the S9 work)
18:22:48 <GeKo> yes, i guess we can find some time for boklm to work on it during august/september maybe once our toolchains are good
18:22:53 <GeKo> should be doable i think
18:23:44 <GeKo> brade: which one?
18:24:20 <brade> so everyone will have their own branch?
18:25:24 <GeKo> you mean pushing the first branch after the esr68 beta merge to tpo infra?
18:25:33 <GeKo> i am still not sure i understand
18:25:38 <brade> yes
18:26:13 <mcs> In previous cycles, I think Arthur started a branch and we worked off it.  That way, some of the essential Tor Browser patches were already available before we did updater work.
18:26:33 <GeKo> i think acat could do that somewhere
18:26:56 <GeKo> which is then the canoncial branch for others to base their parts of the rebase on
18:27:05 <GeKo> acat: does that work for you?
18:27:59 <acat> I can do that, so it would be taking current nightly and start rebasing?
18:28:28 <GeKo> i think we wait until the currently nightly code gets onto the beta branch
18:28:42 <GeKo> and then we'd start rebasing
18:29:02 <GeKo> so, once esr68 is on mozilla-beta essentially
18:29:53 <acat> when is that?
18:30:04 <GeKo> we can chat a bit about the process under the week
18:30:08 <GeKo> i think next week
18:30:11 <brade> acat: May 14 I think
18:30:23 <brade> you might be able to do it a little before then
18:30:59 <acat> ok
18:31:12 <brade> I’m not sure when they make the branch (May 13?)
18:32:42 <boklm> https://wiki.mozilla.org/Release_Management/Calendar has May 13 as "Merge Date"
18:33:07 <GeKo> okay, anything else for today?
18:33:58 <pili> I'm good :)
18:33:59 <GeKo> thanks everyone then *baf*
18:34:01 <GeKo> #endmeeting