17:59:06 #startmeeting anti-censorship meeting 17:59:06 Meeting started Thu Mar 12 17:59:06 2020 UTC. The chair is phw. Information about MeetBot at http://wiki.debian.org/MeetBot. 17:59:06 Useful Commands: #action #agreed #help #info #idea #link #topic. 17:59:16 hi everyone! 17:59:20 here's our meeting pad: https://pad.riseup.net/p/tor-anti-censorship-keep 17:59:22 hi 17:59:30 hi 17:59:34 hello! 17:59:34 hi 18:00:01 everyone: thymbahutymba has been helping me a lot with our obfs4 docker image and decided to join us today 18:00:16 welcome :) 18:00:25 welcome thymbahutymba 18:00:48 our announcement for today is that we now have a gsoc page, woohoo: https://community.torproject.org/gsoc/ 18:00:49 thanks :) 18:01:13 :) 18:01:23 thymbahutymba: fyi, we usually go over announcements and discussion items on our pads, and then talk about dev topics 18:02:11 our only discussion topic for today is #33646 18:02:14 ok, I will try to follow you somehow 18:03:29 adam langley abandoned a github repo that obfs4proxy depended on, which - if i understand correctly - will break tor browser builds (but not nightlies) 18:03:36 oops #33464 18:03:47 oh, thanks dcf1 18:04:02 phw: I checked with boklm on #tor-dev and it doesn't affect Tor Browser builds 18:04:16 I beleive it doesn't affect other builds that use go1.11 or later, either 18:04:45 hmm, ok. then it's slightly less urgent than i thought 18:04:47 The repo still exists and is cloneable, and the working commit is still in its history, it is only the top of master that no longer works. 18:04:47 phw: when and where I should say what I've in mind for docker-obfs4-bridge? 18:05:03 hi! 18:05:35 The ticket also mentions possible implementation problems in ed25519/extra25519, which of course may merit consideration separate from the build issue (the build issue seems minor) 18:05:53 BTW the issue that prompted the recent deprecation of the ed25519 repo was https://github.com/agl/ed25519/issues/27 18:05:55 dcf1: oh, that's because go.sum references the working commit, right? 18:06:08 phw: go.mod rather, but yes 18:07:13 I have tried to understand Elligator in the past and failed, but it would be interesting to see if it affords a distinguishability attack on obfs4 18:08:29 a classic case of obscurity through security 18:09:36 the right way to fix this appears to be to use the ristretto255 library, as suggested by golang's crypto maintainer: https://github.com/golang/go/issues/20504#issuecomment-590654494 18:09:56 just to understand I should put what I did last week on pad? Even if is concerning the docker image? 18:10:13 it's not a drop-in replacement for extra25519 though, so not an easy thing to fix 18:10:31 thymbahutymba: yes feel free to add it to the pad :) no pressure though 18:10:45 thymbahutymba: if you plan on attending our meeting regularly (and i hope you do!), i would encourage you to add it to the pad, yes 18:10:51 thymbahutymba: we'll go over individual things we want help/feedback on later in the meeting 18:11:28 ok, I will put there then. Is not too much but may help 18:12:18 now i wonder why the reporter of #33464 failed to build obfs4proxy if go.mod doesn't reference github.com/agl/ed25519's master? 18:12:38 I asked on the ticket what version of go they are using 18:12:42 maybe an old version of go? 18:12:55 that makes sense, thanks. 18:13:59 for me, this ticket falls onto the pile of "we should be fixing this but other things currently have priority" :/ 18:14:42 any other comments regarding this ticket? 18:15:02 It's possible that the build actualyl is broken even with a recent go, I didn't try with a cleared GOPATH and modules cache. 18:16:52 that's something we should check after the meeting. if it is, a short-term fix would be to either fork agl's repo and revert it, or to add the dependencies to obfs4proxy. neither is great. 18:18:47 so, let's 1) make sure that it actually works and if not, 2) come up with a short-term fix so tor browser continues to be build-able. does that sound reasonable to everyone? 18:19:12 +1 18:19:32 dcf1: thanks for your help with debugging this, btw 18:20:20 next up is our monthly report for february which is way overdue. please add your february highlights to this pad and i'll turn it into our monthly report: https://pad.riseup.net/p/vGR0zvyXCuV3HG09VX-j 18:21:37 cohosh seems to be the only one with 'needs help with' items. how can we help? 18:21:58 the tb patches i'm good on for now 18:22:10 i had a question about obfs4 reachability tests we were doing 18:22:34 for #31701 18:22:41 do we want to keep doing these? 18:22:54 i think we learned some things and there's sponsor 30 work later to do this long term 18:23:44 cohosh: is there a cost to running the tests? in terms of you spending time? 18:24:12 not a large one 18:24:21 i mostly need to remember to have things set up correctly 18:24:26 this may feed the work on s30 that needs to be done 18:24:28 with the input from ooni 18:24:48 yeah that's what i was thinking, that we wanted to do this tests with ooni eventually 18:25:01 there's merit in having data we can inspect, if we wonder "hey, what's been going on during that time" 18:25:02 but i'm not sure what the timeline for that is 18:25:24 okay cool, i will restart the tests and make sure i have a probe point in north america working lol 18:25:26 we could add that ticket under s30 work 18:25:50 i'll also find the ticket for the s30 work and we can revisit this when that gets rolled out? 18:25:54 ...but if you have to spend more than a few minutes on it per week, it may not be worth doing. 18:26:00 do you know the ticket number for it? 18:26:08 phw: it won't be more than a few minutes 18:26:31 all the work for s30 is in here https://trac.torproject.org/projects/tor/wiki/org/sponsors/Sponsor30 Let me look for the ticket and I can add this one 31701 as a child 18:26:46 ok thanks! 18:26:50 cohosh: ok, in that case i'm leaning towards continuing to run the tests if you agree that this is reasonable 18:26:59 yep sounds good :) 18:27:07 thanks 18:27:15 and then my last questions was about #33593 18:27:29 i wanted to start on making a debian package for snowflake 18:27:41 and it seems a good idea to have some concept of a snowflake version 18:27:48 we already have this for the webextension 18:27:54 but not really for the rest of snowflake 18:28:11 so my question there is: do we use the same versioning system for all of snowflake? 18:28:34 or a separate one for each package we want to make (i.e., webextension, proxy-go deb package, and snowflake client deb package)? 18:29:02 so far we've been tagging wtih a prefix 18:29:02 webext-0.2.0 18:29:37 arlolra: you're right 18:30:26 it makes it a bit confusing if we do a version bump for a client change and then suddenly the webext version goes up by more than one 18:30:33 perhaps 18:31:12 having a single version for all components seems simpler and less confusing to me. but then we should make it clear in the changelog what components are affected by a version bump. 18:31:43 or we could break up the mono-repo 18:31:54 not sure if it's an apt analogy but tor also has a single version, regardless of if you're a client, relay, or bridge. 18:31:54 that's another possibility 18:32:25 there isn't any shared code between the browser-based proxy code and the rest of snowflake for example 18:32:34 Since #33330, also keep in mind that vX.Y.Z tags will be interpreted as module versions by Go, in the case of e.g. external code importing a portion of Snowflake code 18:32:35 phw: true, and so does obfs4 18:32:47 dcf1: yeah that's a good point too 18:33:18 which is another reason to move to using version imo, that way we're doing modules more correctly 18:33:56 so what we could do is split out the mono repo into a browser-based proxy repo (mostly JS) and a go snowflake repo? 18:35:05 * phw doesn't have a strong opinion and defers to the folks who have been more active in snowflake dev 18:35:40 my proposal is to split into two repos and then have different versions for those repos 18:35:48 but to keep the same version for all the go snowflake stuff 18:36:39 but i'd only move on this if we have consensus from core snowflake devs (dcf and arlolra and phw) 18:36:54 the "go snowflake" repo would include the server, client, and standalone-proxy, right? 18:37:02 and the broker 18:37:07 oh, right 18:37:42 i've never split a widely used public repo before 18:37:52 so idk what kinds of gotchas live there 18:38:24 maybe propose it on the ticket and give some time to think about it 18:38:33 yep that sounds good 18:38:39 arlolra: +1 18:38:43 I imagine one of them would be a fork to preserve the git history 18:38:52 * cohosh nods 18:39:14 why you don't create new repository and take the old one archived? 18:39:26 two new repository* 18:40:43 agix: hey, i think i owe you bridgedb reviews! i'm sorry it's taking so long :/ 18:42:35 folks i have a small thing to share, could i? 18:42:37 cohosh: i think we have a plan regarding #33330. shall we move on? 18:42:42 antonela: please do 18:42:42 yep thanks! 18:42:50 thanks! so someone is eager to discuss bridges in the ux mailing list, im sharing it here just if you missed it 18:42:57 https://lists.torproject.org/pipermail/ux/2020-February/000491.html 18:43:04 no hurries i think, but maybe is useful 18:43:15 * cohosh subscribes to ux mailing list >.< 18:43:20 (: 18:43:40 phw: no problem really :) those reviews are not that urgent and i know you just came back from vacay 18:43:54 hm. i think i replied to this person on a different mailing list.. a few weeks ago? 18:44:18 maybe? or at the ux list but a different thread? 18:44:22 i dunno 18:44:23 the proposal seemed ill-informed to me, but i was also struggling with understanding it, so there's that. 18:44:49 its fine 18:44:52 thank you! 18:45:06 oh, actually it was the ux list. back in december last year. 18:45:16 I'm with phw, I stopped paying attention to that poster 18:45:21 https://lists.torproject.org/pipermail/ux/2019-December/000477.html 18:45:41 oki, we are good then 18:45:43 phw tried to gently suggest where they were misguided, and they didn't seem to take it to heart or understand the criticism 18:45:52 classic 18:46:02 maybe i'll follow up again, but it's not very high priority right now :/ 18:46:09 other volunteers need attention too 18:46:14 I don't think we're going to be implementing DRM into bridge clients to prevent users from extracting a secret key 18:46:23 perfect, thanks folks! 18:46:24 ...speaking of which: thymbahutymba, let's talk about your work? 18:46:41 ok 18:47:54 thymbahutymba: i believe i owe you reviews on several trac tickets 18:48:11 I proposed few weeks ago #33461 in order to increase the number of user that can use the docker image 18:48:19 I'm actually one of them due to the fact that I'm running my bridge on rpi3 18:49:17 you have probably seen #33088, right? 18:49:45 What is needed is also in a new repository that I own, because I don't know how to fork yours and propose pull request, where in the multiarch branch there what is needed in order to have images for different arch: x86_64, arm and arm64 18:50:13 phw: sorry but no 18:50:34 i believe you need an account on dip.torproject.org to fork repositories there. but it should be possible to check out the repository, and then push it to somewhere else, like github. 18:51:05 thymbahutymba: i spent a bit of time looking into this. there's an experimental docker module that facilitates this on linux, but it's... experimental 18:51:22 gitlab.torproject.org is now 18:53:28 phw: the experimental part should be only for the manifest. I use it for different things and it works fine. Other then that in order to build such kind of image there is the qemu-user-static container. 18:54:04 As I pointed in #33461 you can see the final result at https://hub.docker.com/r/thymbahutymba/obfs4-bridge 18:54:09 thymbahutymba: it's been a while since i played with this. i think my current status is that i could build multi-arch images but i couldn't test them locally because this seems currently unsupported. 18:55:07 thymbahutymba: either way, i need to catch up on your work. i don't understand this enough to say anything smart right now 18:55:57 ok :) then I think it's the same for the docker-compose for deploy the container I guess #31834 (comment 26) 18:56:02 btw, i'm also fine with git-formatted patches if that works for you. it doesn't have to be a pull request. 18:56:57 ...or i fork the repo to github, which should make it easier for us to iterate on patches 18:56:59 and I should attach the patch file to ticket? 18:57:53 let's go the github route, ok? i think it's easiest. i'll fork the existing obfs4-docker-image repo to a github repo, which you can then fork. 18:58:18 sounds good 18:58:31 thanks again for your help, i really appreciate it! 18:58:46 anything else? we have one minute left :) 18:59:00 then I will submit everything on github? 18:59:03 arlolra: I think you need to merge https://github.com/keroserene/go-webrtc/pull/110, I don't have permission 18:59:13 I mean as pull-request? 18:59:19 thymbahutymba: yes, let's take care of everything on github, as a pull request. 18:59:58 phw: ok thanks :) 19:00:20 dcf1: ok, will do 19:00:34 let's wrap it up for today. thanks everyone for attending and see you next week! 19:00:37 #endmeeting