17:00:14 #startmeeting anti-censorship weekly checkin 2019-08-22 17:00:14 Meeting started Thu Aug 22 17:00:14 2019 UTC. The chair is phw. Information about MeetBot at http://wiki.debian.org/MeetBot. 17:00:14 Useful Commands: #action #agreed #help #info #idea #link #topic. 17:00:18 hi everyone 17:00:25 hi 17:00:32 our meeting pad is available here: https://pad.riseup.net/p/tor-censorship-2019-keep 17:00:40 hi 17:01:00 hi 17:02:24 our first discussion item is a mailing list post on tor-relays@: https://lists.torproject.org/pipermail/tor-relays/2019-August/017647.html a relay was dealing with a lot of connections from iranian addresses iiuc 17:02:53 i have no idea what this might be all about. maybe related to #30636? 17:03:45 but maybe anyone else has a guess? 17:04:32 IR user numbers are much elevated since the baseline a few months ago, but pretty steady the last 2 months. 17:04:35 https://people.torproject.org/~dcf/metrics-country.html?start=2019-05-01&country=ir 17:06:20 I hadn't heard about this, but I don't see any clear connection to censorship, except that it was Iranian(?) IPs connecting to an exit(?) relay. 17:06:40 yes, that was my thought too 17:07:13 anyway, let's move on. i was just curious if anyone could make more of this post. 17:07:43 we have the gettor roadmap: https://dip.torproject.org/torproject/anti-censorship/gettor/-/boards 17:07:47 * phw wonders if hiro is here 17:08:31 hiro: you had some plans for next steps for gettor 17:08:50 i think the tor browser copies in github/gitlab are outdated 17:09:07 phw: what do you mean? 17:09:30 the links that gettor sends you over email are outdated. it should give you the latest tor browser copies but it doesn't. 17:09:31 I heard that as well. Someone at FOCI said they had set up their own Tor Browser distribution on GitHub to work around tpo's being outdated. 17:09:43 ah, yes 17:10:00 this shouldn't be too hard to automate, i would think. if only we had enough time to work on it :/ 17:11:05 * gaba is looking for a ticket about tor browser outdated in gettor links 17:11:12 https://github.com/TheTorProject/gettorbrowser links to 8.0.2 17:12:11 also, we really really need some basic documentation. i started https://trac.torproject.org/projects/tor/wiki/org/teams/AntiCensorshipTeam/GetTorSurvivalGuide 17:12:16 which is from last October https://blog.torproject.org/new-release-tor-browser-802 17:13:17 can any of you create a ticket for the links being outdated? 17:13:25 will do, gaba 17:13:30 thanks! 17:13:41 anyway, let's talk more if hiro shows up and continue in the meanwhile 17:13:46 It seems that updating that and automatizing should be a prioirity 17:13:49 yes 17:13:58 I was here sorry updating the pad 17:14:10 hi hiro! 17:14:21 yes the links got outdated when the recommended browser version changed 17:14:25 I have to fix that 17:14:31 I have it for this week 17:14:44 it is automated via gitlab pipeline pushing to github and gitlab 17:15:13 hiro: oh, the updating process already is automated? 17:15:16 yes 17:15:20 neat 17:15:33 everyday there is a CI checking the browser version 17:15:36 and updating the files 17:15:46 problem is it's broken atm 17:16:20 how can we help fixing it? 17:16:43 I have it for today 17:16:45 to fix it 17:17:03 I will nevertheless give you access to the repository where the pipeline lives 17:17:13 I think atm only me and dgoulet have access 17:18:07 becaue dgoulet set up that gitlab account 17:18:44 anyways today it will be fixed 17:19:14 cool, thanks hiro 17:19:21 anything else that is urgent related to gettor? 17:19:22 anything else that's critical in gettor? 17:19:26 hehe 17:19:45 I think this and documenting everything 17:19:50 also having a better deploy method 17:20:03 this is the ci: https://gitlab.com/thetorproject/gettorbrowser/blob/master/.gitlab-ci.yml 17:20:10 documentation would be very helpful because it allows others to take over and contribute without relying so much on hiro 17:20:35 hiro: do we have tickets in trac for deployment? if we don't please create one and we link it to the roadmap for next week 17:20:40 I'm just reading but is there a way to utilize webhooks here? 17:20:54 webhooks from gitlab? 17:20:59 whenever there's a new TB release Gettor gets the new builds 17:21:20 I am using ci in gitlab 17:21:29 oh 17:21:48 are there webhooks wherever the original builds are hosted? 17:21:59 on dist.tpo 17:22:10 it's just files listed on apache 17:22:24 how about we continue with the roadmap once we have addressed the critical issues in gettor? 17:22:28 for reference clash: https://gitlab.com/thetorproject/gettorbrowser/blob/master/.gitlab-ci.yml 17:22:30 what do you think gaba? 17:22:42 phw: yes, sounds good 17:23:03 I just updated with the work hiro is planning for next week 17:24:15 let's move on to release engineering. here's how it works for bridgedb: 17:24:55 we're using semantic versioning for bridgedb's version number and this git development model: https://nvie.com/posts/a-successful-git-branching-model/ 17:25:06 every now and then, when i have time, we're releasing a new bridgedb version 17:25:31 that's about it. we get away with this rather informal process because we are running the only bridgedb deployment ;) 17:26:12 gaba: you were thinking about topics like planned releases, right? 17:26:35 i'm trying to understand what we should be doing that we aren't doing already. 17:26:39 yes. I was wondering if there is any release that should be better if planned. 17:26:56 would* 17:27:33 gettor is in a similar situation than bridgedb 17:27:34 do you mean by that "we have a new release every month" or "we anticipate feature X to release on Y"? 17:28:07 That we put features/bug-fixing/changes together to release all at the same time (depending on minor or major changes) 17:28:33 how is working with snowflake? 17:28:59 phw: if we are ok this way and we do not need to change to a schedule then is fine with me. 17:30:09 With snowflake we have been making releases only as needed, for example pushing new proxy code to the website and making new webextension uploads whenever we need new proxy behavior 17:30:10 basically, that's what we are doing with bridgedb because of https://nvie.com/posts/a-successful-git-branching-model/. i'm a fan of this method. basically, the master branch only has releases while the development branch is for, well, development. new features and bug fixes branch off of the development branch and are eventually merged back into the master branch. 17:30:25 or upgrading the client in Tor Browser whenever we need new client behavior 17:31:14 yes. I like having the develop branch as the source and not master. 17:31:35 ok. thanks 17:32:16 i'm all for getting more organised but i'm not sure if i see a problem here that needs solving. 17:32:31 yes, it seems we are fine and we do not need anything else on planning here. 17:32:49 do you see a need to improve things on snowflake's side dcf1? 17:33:30 The only thing is we're disorganized when it comes to updating all the channels, e.g. with publishing a new webextension and also updating the hosted proxy at snowflake.torproject.org. 17:33:56 But we don't really have critical dependencies that *require* close coordination. 17:35:15 Example is https://trac.torproject.org/projects/tor/ticket/31250#comment:12, which is still open because I don't know if Cupcake has updated yet. 17:36:26 a somewhat related thought: bridgedb could really use a staging server. many bugs only manifest once they're in production and messing with our production server is a very sloppy way of debugging. 17:37:12 but i guess that's more quality assurance and less release engineering 17:37:40 yes, still important. Let's check with anarcat on how to get one 17:37:52 hum? 17:38:21 hey phw gaba isn't bridge db on a special server? 17:38:31 hiro: it's on polyanthum 17:38:36 w special I mean a bare metal that has specifc requirements? 17:38:42 oh, that i don't know. 17:38:47 dcf1: not sure what we would be next step with #31250. Is this something about coordinating with somebody else not here? 17:39:30 also bridgedb gets bridges from the bridges authority do you plan to have a staging w real bridges or just test addresses? 17:39:31 gaba: nothing we need to talk about now. It's mostly solved. Just need to confirm with saint whether it's happened in Cupcake yet or not. 17:39:54 ok 17:39:58 I can help you setup this as when I setup the azure meek I did some testing with a bridgedb instance 17:40:35 hiro: i may be naive, but a second bridgedb instance on the same machine may be helpful. i don't want it to be used by people, but i want it to operate on the same bridges as the live instance. 17:41:10 worst that can happen, on the same machine, is it takes the machine down because of resource usage 17:41:14 or that operators confuse the two 17:41:21 yes! 17:42:04 if it's on the same machine, i would want it at, say, bridges.tp.o/staging/. operators wouldn't be exposed to it unless they are actively looking for it. 17:42:27 anyway, let's file a ticket and continue there, ok? 17:42:36 ok 17:42:41 i won't see it until sept 3rd, btw 17:42:41 thanks hiro and anarcat 17:42:47 i'm on vacation for a bit 17:42:52 enjoy vacas! 17:42:53 but weasel's around 17:42:54 it's not urgent 17:43:25 ok, next point on our discussion list is snowflake localisation! 17:43:41 you should all know that snowflake means schneeflocke in german 17:43:42 *localization 17:43:47 :) 17:44:25 copo de nieve 17:44:32 it is not in the roadmap but emmapeel worked on it and now it is ready :) 17:45:01 * phw has approximately 0 experience with locali[zs]ation 17:45:08 thanks emmapeel! 17:45:32 We do not have to do it now but it would be good to include it in the roadmap for s28 work with snowflake 17:46:15 sounds good to me. i hope somebody can figure out how to make use of translations :) 17:46:54 ok, last point is bridgedb's anti-bot mechanism. i wanted to catch you up on what we've done so far 17:47:19 we recently deployed #31252 in an effort to make it harder for bots to fetch bridges 17:48:32 i recently set up a decoy bridge that is handed out to requests that are coming from bots. the only purpose of this decoy bridge is to try and find out what our adversaries are doing with it 17:48:55 remember that bridgedb sees tons of automated requests that are surprisingly good at solving our captcha 17:49:17 i had a brief look at the logs of my default bridge and almost all connections are coming from china 17:49:46 "default" as in default Tor Browser bridge? not the decoy you mentioned? 17:49:47 our vps in china cannot connect to my decoy bridge either. 17:49:57 sorry, s/default/decoy/ 17:50:16 The decoy is only given to suspected bots? 17:50:16 (the decoy bridge is private and doesn't report itself to the bridge authority) 17:51:19 that's it. i thought it's an interesting finding worth sharing. 17:51:19 I wonder why it would be made inaccessible and also connected to from addresses in China. 17:51:48 dcf1: my guess is that the bridgedb crawler is run by gfw engineers. 17:51:49 maybe the bots are a way to discover bridges 17:52:31 i suspect that the decoy bridge ended up on the same "probing list" as all the other bridges that the gfw discovered by doing dpi 17:52:47 that would make sense 17:54:03 now that i think about it: i remember seeing connections to my bridge's obfs4 port. i wonder if they have a probing module for obfs4 but don't have a "detection module" for it 17:54:34 i'm happy to share the pcaps if anyone wants to have a closer look 17:55:43 ok, we're almost done for today. shall we move on to the "needs help with" part? 17:56:11 #31460 is a problem, yes. 17:56:15 i see that dcf1 already commented on #31460. that was a bug report from serna 17:57:10 i'll take the liberty of making cohosh the reviewer for #17626 17:58:18 arlo needs a review for #30310 17:58:38 It's one of the tickets I need to catch up on. 17:58:38 and dcf1 for #31454 17:59:42 I will do it if no one else does within a week. 17:59:47 i'll do #31454 with cohosh's help. i just updated to go 1.12.9 to re-deploy bridges.tp.o/scan/ 18:00:02 #30310 was for august but it has #31384 as a child. That last one may need to be for september. 18:00:58 i think we're done for today. anything left? 18:01:29 #endmeeting