17:59:06 <phw> #startmeeting anti-censorship meeting
17:59:06 <MeetBot> 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 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
17:59:16 <phw> hi everyone!
17:59:20 <phw> here's our meeting pad: https://pad.riseup.net/p/tor-anti-censorship-keep
17:59:22 <cohosh> hi
17:59:30 <thymbahutymba> hi
17:59:34 <antonela> hello!
17:59:34 <agix> hi
18:00:01 <phw> everyone: thymbahutymba has been helping me a lot with our obfs4 docker image and decided to join us today
18:00:16 <cohosh> welcome :)
18:00:25 <antonela> welcome thymbahutymba
18:00:48 <phw> our announcement for today is that we now have a gsoc page, woohoo: https://community.torproject.org/gsoc/
18:00:49 <thymbahutymba> thanks :)
18:01:13 <antonela> :)
18:01:23 <phw> thymbahutymba: fyi, we usually go over announcements and discussion items on our pads, and then talk about dev topics
18:02:11 <phw> our only discussion topic for today is #33646
18:02:14 <thymbahutymba> ok, I will try to follow you  somehow
18:03:29 <phw> 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 <dcf1> oops #33464
18:03:47 <phw> oh, thanks dcf1
18:04:02 <dcf1> phw: I checked with boklm on #tor-dev and it doesn't affect Tor Browser builds
18:04:16 <dcf1> I beleive it doesn't affect other builds that use go1.11 or later, either
18:04:45 <phw> hmm, ok. then it's slightly less urgent than i thought
18:04:47 <dcf1> 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 <thymbahutymba> phw: when and where I should say what I've in mind for docker-obfs4-bridge?
18:05:03 <gaba> hi!
18:05:35 <dcf1> 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 <dcf1> BTW the issue that prompted the recent deprecation of the ed25519 repo was https://github.com/agl/ed25519/issues/27
18:05:55 <phw> dcf1: oh, that's because go.sum references the working commit, right?
18:06:08 <dcf1> phw: go.mod rather, but yes
18:07:13 <dcf1> 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 <phw> a classic case of obscurity through security
18:09:36 <phw> 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 <thymbahutymba> just to understand I should put what I did last week on pad? Even if is concerning the docker image?
18:10:13 <phw> it's not a drop-in replacement for extra25519 though, so not an easy thing to fix
18:10:31 <cohosh> thymbahutymba: yes feel free to add it to the pad :) no pressure though
18:10:45 <phw> 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 <cohosh> thymbahutymba: we'll go over individual things we want help/feedback on later in the meeting
18:11:28 <thymbahutymba> ok, I will put there then. Is not too much but may help
18:12:18 <phw> 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 <dcf1> I asked on the ticket what version of go they are using
18:12:42 <cohosh> maybe an old version of go?
18:12:55 <phw> that makes sense, thanks.
18:13:59 <phw> for me, this ticket falls onto the pile of "we should be fixing this but other things currently have priority" :/
18:14:42 <phw> any other comments regarding this ticket?
18:15:02 <dcf1> 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 <phw> 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 <phw> 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 <cohosh> +1
18:19:32 <phw> dcf1: thanks for your help with debugging this, btw
18:20:20 <phw> 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 <phw> cohosh seems to be the only one with 'needs help with' items. how can we help?
18:21:58 <cohosh> the tb patches i'm good on for now
18:22:10 <cohosh> i had a question about obfs4 reachability tests we were doing
18:22:34 <cohosh> for #31701
18:22:41 <cohosh> do we want to keep doing these?
18:22:54 <cohosh> i think we learned some things and there's sponsor 30 work later to do this long term
18:23:44 <phw> cohosh: is there a cost to running the tests? in terms of you spending time?
18:24:12 <cohosh> not a large one
18:24:21 <cohosh> i mostly need to remember to have things set up correctly
18:24:26 <gaba> this may feed the work on s30 that needs to be done
18:24:28 <gaba> with the input from ooni
18:24:48 <cohosh> yeah that's what i was thinking, that we wanted to do this tests with ooni eventually
18:25:01 <phw> there's merit in having data we can inspect, if we wonder "hey, what's been going on during that time"
18:25:02 <cohosh> but i'm not sure what the timeline for that is
18:25:24 <cohosh> okay cool, i will restart the tests and make sure i have a probe point in north america working lol
18:25:26 <gaba> we could add that ticket under s30 work
18:25:50 <cohosh> i'll also find the ticket for the s30 work and we can revisit this when that gets rolled out?
18:25:54 <phw> ...but if you have to spend more than a few minutes on it per week, it may not be worth doing.
18:26:00 <cohosh> do you know the ticket number for it?
18:26:08 <cohosh> phw: it won't be more than a few minutes
18:26:31 <gaba> 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 <cohosh> ok thanks!
18:26:50 <phw> cohosh: ok, in that case i'm leaning towards continuing to run the tests if you agree that this is reasonable
18:26:59 <cohosh> yep sounds good :)
18:27:07 <phw> thanks
18:27:15 <cohosh> and then my last questions was about #33593
18:27:29 <cohosh> i wanted to start on making a debian package for snowflake
18:27:41 <cohosh> and it seems a good idea to have some concept of a snowflake version
18:27:48 <cohosh> we already have this for the webextension
18:27:54 <cohosh> but not really for the rest of snowflake
18:28:11 <cohosh> so my question there is: do we use the same versioning system for all of snowflake?
18:28:34 <cohosh> 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 <arlolra> so far we've been tagging wtih a prefix
18:29:02 <arlolra> webext-0.2.0
18:29:37 <cohosh> arlolra: you're right
18:30:26 <cohosh> 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 <cohosh> perhaps
18:31:12 <phw> 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 <arlolra> or we could break up the mono-repo
18:31:54 <phw> 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 <cohosh> that's another possibility
18:32:25 <cohosh> there isn't any shared code between the browser-based proxy code and the rest of snowflake for example
18:32:34 <dcf1> 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 <cohosh> phw: true, and so does obfs4
18:32:47 <cohosh> dcf1: yeah that's a good point too
18:33:18 <cohosh> which is another reason to move to using version imo, that way we're doing modules more correctly
18:33:56 <cohosh> 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 <cohosh> my proposal is to split into two repos and then have different versions for those repos
18:35:48 <cohosh> but to keep the same version for all the go snowflake stuff
18:36:39 <cohosh> but i'd only move on this if we have consensus from core snowflake devs (dcf and arlolra and phw)
18:36:54 <phw> the "go snowflake" repo would include the server, client, and standalone-proxy, right?
18:37:02 <cohosh> and the broker
18:37:07 <phw> oh, right
18:37:42 <cohosh> i've never split a widely used public repo before
18:37:52 <cohosh> so idk what kinds of gotchas live there
18:38:24 <arlolra> maybe propose it on the ticket and give some time to think about it
18:38:33 <cohosh> yep that sounds good
18:38:39 <phw> arlolra: +1
18:38:43 <arlolra> I imagine one of them would be a fork to preserve the git history
18:38:52 * cohosh nods
18:39:14 <thymbahutymba> why you don't create new repository and take the old one archived?
18:39:26 <thymbahutymba> two new repository*
18:40:43 <phw> agix: hey, i think i owe you bridgedb reviews! i'm sorry it's taking so long :/
18:42:35 <antonela> folks i have a small thing to share, could i?
18:42:37 <phw> cohosh: i think we have a plan regarding #33330. shall we move on?
18:42:42 <phw> antonela: please do
18:42:42 <cohosh> yep thanks!
18:42:50 <antonela> 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 <antonela> https://lists.torproject.org/pipermail/ux/2020-February/000491.html
18:43:04 <antonela> no hurries i think, but maybe is useful
18:43:15 * cohosh subscribes to ux mailing list >.<
18:43:20 <antonela> (:
18:43:40 <agix> phw: no problem really :) those reviews are not that urgent and i know you just came back from vacay
18:43:54 <phw> hm. i think i replied to this person on a different mailing list.. a few weeks ago?
18:44:18 <antonela> maybe? or at the ux list but a different thread?
18:44:22 <antonela> i dunno
18:44:23 <phw> the proposal seemed ill-informed to me, but i was also struggling with understanding it, so there's that.
18:44:49 <antonela> its fine
18:44:52 <antonela> thank you!
18:45:06 <phw> oh, actually it was the ux list. back in december last year.
18:45:16 <dcf1> I'm with phw, I stopped paying attention to that poster
18:45:21 <phw> https://lists.torproject.org/pipermail/ux/2019-December/000477.html
18:45:41 <antonela> oki, we are good then
18:45:43 <dcf1> 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 <antonela> classic
18:46:02 <phw> maybe i'll follow up again, but it's not very high priority right now :/
18:46:09 <phw> other volunteers need attention too
18:46:14 <dcf1> 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 <antonela> perfect, thanks folks!
18:46:24 <phw> ...speaking of which: thymbahutymba, let's talk about your work?
18:46:41 <thymbahutymba> ok
18:47:54 <phw> thymbahutymba: i believe i owe you reviews on several trac tickets
18:48:11 <thymbahutymba> I proposed few weeks ago #33461 in order to increase the number of user that can use the docker image
18:48:19 <thymbahutymba> I'm actually one of them due to the fact that I'm running my bridge on rpi3
18:49:17 <phw> you have probably seen #33088, right?
18:49:45 <thymbahutymba> 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 <thymbahutymba> phw: sorry but no
18:50:34 <phw> 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 <phw> 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 <gaba> gitlab.torproject.org is now
18:53:28 <thymbahutymba> 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 <thymbahutymba> As I pointed in #33461 you can see the final result at https://hub.docker.com/r/thymbahutymba/obfs4-bridge
18:54:09 <phw> 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 <phw> 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 <thymbahutymba> ok :) then I think it's the same for the docker-compose for deploy the container I guess #31834 (comment 26)
18:56:02 <phw> 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 <phw> ...or i fork the repo to github, which should make it easier for us to iterate on patches
18:56:59 <thymbahutymba> and I should attach the patch file to ticket?
18:57:53 <phw> 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 <thymbahutymba> sounds good
18:58:31 <phw> thanks again for your help, i really appreciate it!
18:58:46 <phw> anything else? we have one minute left :)
18:59:00 <thymbahutymba> then I will submit everything on github?
18:59:03 <dcf1> arlolra: I think you need to merge https://github.com/keroserene/go-webrtc/pull/110, I don't have permission
18:59:13 <thymbahutymba> I mean as pull-request?
18:59:19 <phw> thymbahutymba: yes, let's take care of everything on github, as a pull request.
18:59:58 <thymbahutymba> phw: ok thanks :)
19:00:20 <arlolra> dcf1: ok, will do
19:00:34 <phw> let's wrap it up for today. thanks everyone for attending and see you next week!
19:00:37 <phw> #endmeeting