Hi!
Our weekly meeting just finished and here come, as usual, the notes. The chat log can be found on
http://meetbot.debian.net/tor-meeting/2018/tor-meeting.2018-04-23-17.59.log....
and our pad items are/were:
Monday, April 23, 2018
Discussion question(s): Arthur asks: We seem to have mar files stored in two places: dist.torproject.org/torbrowser/ and cdn.torproject.org/aus1/torbrowser/ weasel asked if we need to increase space in both places. (https://trac.torproject.org/projects/tor/ticket/25575#comment:3) I'm wondering if these two sets of mar files are redundant, or if they are different things and we indeed need to roughly double the space of both things in order to increase the number of locales by ~2x. [arthur plans to add new calculations to #25575] boklm asks: disk space on build-sunet-a is full again. I am wondering if we could increase the disk size on this VM. [boklm just asked on #tor-project]
mcs and brade: Last week: - Continued rebasing Tor Browser updater patches for ESR60 (part of #25543). - Helped with triage of incoming tickets. - Attended the Snowflake meeting. - Participated in the UX/Tor Browser "sync" meeting. This week: - Continue rebasing Tor Browser updater patches for ESR 60. - Monitor #25807 (Can not request bridges from torproject.org (App Engine is broken for moat)).
sysrqb: Last week: Continued troubleshooting https-everywhere add-on update (#25603) - It seems https-everywhere webextension does not work in Fennec 52.7.3 - Still testing modified version of https-e v5.2.21 Troubleshooting crash during start-up of Fennec 61.0a1 with rebased Orfox patches (#25741) - Crash caused by MOZ_CRASH() call due to failure during EGL (graphics library) setup - Reproducible without Orfox patches, fetching current mozilla-central and will rebuild using that
- hmm, now that I think about it, i forgot to clobber first, maybe caused by remaining compilation
This week: More of troubleshooting the above tickets Reviewing upstream Mozilla bugs affecting Mozilla 52ESR code
GeKo: Last week -worked mostly on getting rustc ready for our Tor Browser builds * slight progress on getting rust compiled for osx but I did not finish that yet (#25779) * wrote a patch for the 64bit Windows cross-compilation; it's working and i get esr60 compiled with it; tor needs to get fixed though (#25895) * we might have trouble getting the 32bit Windows cross-compilation going due to exception handling issue, see: https://github.com/rust-lang/rust/issues/12859 -write patches to get esr60 compiled for Windows (#25554, #25832) -opened tickets to clean up our CFLAGS/LDFLAGS usage for Windows which is pretty confusing (#25859, #25860, #25862) -bisected on the weekend our compilation issue when STL wrappers are enabled for 64bit Windows (#23231); it seems https://bugzilla.mozilla.org/show_bug.cgi?id=1443823 is fixing that one, too -reviewed #25458 (UI customization half-broken in Tor Browser 8.0a3) and #24309 -reviewed a bunch of Fennec bugs we might want to consider to backport for the next Orfox release -signed the alpha release -a bit bug triage This week -fix osx rust cross-compilation -further investigate 32bit Windows rust cross-compilation -review remaining Fennec bugs we could consider for backport -review the rebased Tor Browser patches (#25543) -bug triage (torbutton and tor bundles/installation components) -maybe if time permits finally fixing https://bugzilla.mozilla.org/show_bug.cgi?id=1390583 (Stylo: Build Broken with MinGW)
igt0: Last Week: Continued testing fingerprinting and linkability defenses - Android Accessible Services can allow external apps to detect users typing their passwords, so it is recommend to us to disable #25902 (Disable Firefox Mobile accessibility services) - Tested if the desktop linkability patches work on Mobile This week: Make sure I didn't miss any other android fingerprint attack vector Rebase and test my tor button branch against the rebased Tor Mobile branch.
arthuredelstein: Last week: - Posted my rebase results (#25543) - Rebased #25543 again to latest mozilla-beta - Worked on fixing circuit display problem on windows. The issue is causes by a strange browser bug related to XUL. I am working on tracking down that bug, and also developing a workaround in case that fix doesn't work. - Built and signed the alpha (with boklm's help) - Looked at #22343 again (Save as... in the context menu results in using the catch-all circuith) This week: - Finally fix circuit display on Windows - Post a patch for #22343 - Try to get tor-browser-build working with the #25543 branch
pospeselr:
Last Week:
- fought off a cold
- various patch revisions for #20283 uplift (Tor Browser should run without a `/proc` filesystem)
- went through outstanding issues for #25147 (Backport of fix shipped in Firefox 58.0.1?)
- patch for #25458 (UI customization half-broken in Tor Browser 8.0a3)
gk: looked into it this morning and verified the newTab.js change is actually not needed for UI customization screen to work
will update the patch once my trac login issues are handled [GeKo: kk]
This Week:
- #23247 !!! (Communicating security expectations for .onion)
tjr - Found a fixed a MinGW bug that was causing crashes - (But it was with those graphics prefs enabled - my patch disabling them was incorrect. I resolved that and am investigating a 'new' crash)
boklm: Last week: - helped build and publish the new alpha - finished setup of new nightly build VM which is now running at http://f4amtbsowhix7rrf.onion/ - worked on the following tickets: - #25817: Add ansible scripts for setup of nigthly build server - #25318: Add Tor Browser nightly builds email notification - #25862: Clean up wrapper script/CFLAGS and friends mix on Windows - #25834: Use compiler dependent spec files for mingw-w64 This week: - investigate reproducibility issue with binutils update (#12968) [#16742] - work on fixing testsuite issues - setup a new VM for running testsuite on nightly builds - work on cleaning up our CFLAGS/LDFLAGS usage for Windows
Georg