15:58:43 #startmeeting tor anti-censorship meeting 15:58:43 Meeting started Thu Jul 14 15:58:43 2022 UTC. The chair is meskio. Information about MeetBot at http://wiki.debian.org/MeetBot. 15:58:43 Useful Commands: #action #agreed #help #info #idea #link #topic. 15:58:49 hello everyone!! 15:58:51 here is our meeting pad: https://pad.riseup.net/p/tor-anti-censorship-keep 15:58:55 Hi~ 15:59:03 feel free to add what you've been working on and put items on the agenda 16:00:32 the first point in the agenda is from previous weeks, our DTLS signature problem in Russia 16:01:14 shelikhoo: AFAIK you have created a TB installer with the modified version, is that accessible somewhere? 16:01:36 Yes https://gitlab.torproject.org/tpo/anti-censorship/team/-/issues/83#note_2820655 16:01:56 It have been uploaded to people site 16:02:10 what is the url to download it? 16:02:31 however, I was unable to independently verify the patch is working 16:02:32 https://people.torproject.org/~shelikhoo/dqo8apcai4/tor-browser/tor-browser-11.5a13-linux-x86_64-176893/tor-browser-linux64-11.5a13_en-US.tar.xz 16:02:42 if linux + amd64 16:02:45 then this url 16:02:46 you mean to test it in russia? 16:02:50 nice, thanks 16:03:00 no, test it to check supported group 16:03:21 during my testing, the snowflake-client always work as DTLS server 16:03:47 so I didn't have the way to check the dtls client hello of snowflake client 16:04:36 I see 16:05:10 how do you want to proceed? should we hand it to users in russia and see what they report? 16:06:52 alternatively, we could also setup a broker and configure all kind of environment.... until we could make the snowflake-client a dtls client 16:06:58 unsure which way is the best 16:09:04 I guess setting up a broker will take some efford, but if we are not sure people will be able to reproduce the problem otherways I'm ok with it 16:11:00 Yes, but maybe we could just send out the browser to those affected and request their feedback 16:11:11 sounds good 16:11:24 I'm not sure we have a direct contact of people affected 16:11:28 the issue is that... I don't think we have a clear idea on how dtls client server role is chosen 16:11:49 but we can post in nftp.party or ask ggus to distribute it 16:12:32 shelikhoo: I see, and maybe only proxies will be choosen as dtls client the way we use pion? 16:13:16 yes, maybe post in the ntf or tor forum first, we are still awaiting distributed snowflake server rollout tweet from community team I think 16:13:33 I don't know if we wants to start queuing on request 16:13:59 sounds good, I think we don't need to pass it over the comms team, we can just post it ourselves both in nft and tor forum 16:14:01 meskio: we could try, or read source to find out 16:14:06 yes 16:14:20 I think for the tor browser we could just post ourself 16:14:29 +1 16:15:05 do you want to do it? or you prefer if I do it? 16:15:14 I will do the posting 16:15:20 great, thanks :) 16:15:22 Yes 16:15:44 let's see what feedback we get 16:15:51 anything else on this topic? 16:16:44 yes, I will also contact valdikss(the one send the patch to pion) in PM to request a testing 16:17:00 ohh, true, good idea :) 16:17:00 if valdikss is willing and able 16:17:02 yes 16:17:47 and nothing more from me 16:17:56 the next topic is about git.torproject.org, TPA wants to deprecate it 16:18:07 there is no timeline, and I assume will take many months 16:18:12 but we should prepare for it 16:18:21 I created an issue in our repo to track what we need there: 16:18:25 https://gitlab.torproject.org/tpo/anti-censorship/team/-/issues/86 16:18:44 my mayor concern is that many go packages uses git.tpo urls as their module name 16:18:58 I'm not sure what will be the best way to do the migration 16:19:15 I guess we can ask TPA to do redirects, so the go fetch commands are still working 16:19:31 but we should change their module name to use gitlab.tpo 16:19:50 I guess this change requires a mayor version bump to don't break anything 16:19:54 isn't it? 16:20:21 for example goptlib and snowflake are being used outside our team 16:20:41 If they remove the git.tpo url without redirection, then it will break anyway in theory 16:21:13 so it is not like we could prevent the break by increase the major version number 16:21:19 go has a proxy cache and in theory packages that dissapear are kept there, so it might not break directly 16:21:59 but we should do it for semantic version 16:22:08 yep 16:22:12 yes! 16:23:43 I don't think we need to act on it yet, but let's keep planning for it 16:24:00 yes. It is not going to happen overnight 16:24:05 another afected package is goptlib, as is not mirrored in gitlab 16:24:14 should we create a https://gitlab.torproject.org/tpo/anti-censorship/goptlib? 16:24:25 or any ideas for a better place for it? 16:24:59 or maybe https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports 16:25:07 it is ptlib after all 16:25:11 yes, true, maybe there 16:25:52 mmm, dcf is not around, AFAIK is the main author 16:26:12 I check with dcf and if he is ok we'll move it to pluggable-transports 16:26:18 yes! 16:27:38 another question related to the move into gitlab is that gitlab does increase the attack vector and might make sense to sign commits 16:27:50 some months ago I wrote a commit signing policy 16:28:09 https://gitlab.torproject.org/tpo/anti-censorship/team/-/issues/8#note_2735441 16:28:12 I mean, a proposal 16:28:36 shelikhoo, itchyonion: when you have some time have a look to it and tell me what you think about it 16:29:34 meskio: Yes, let's discuss this in the ticket. 16:29:39 +1 16:30:20 I'll keep track of TPA movements on this matter and move forward the needed changes in our side slowly 16:31:02 this ones are the only problems I thought of with the change 16:32:02 should we move to the next topic? 16:32:25 nothing more from me on this topic right now 16:32:31 the last topic I have for today is bridge:// URIs and QR codes 16:32:42 QR codes for bridges are right now a mess 16:33:06 bridgedb use a pretty hacky format of a python list encoded into the QR code 16:33:20 Tor Browser produces their own with a single bridge line into it 16:33:31 I think it will be nice to formalize them 16:33:51 pier wrote a proposal for a bridge:// custom URI: 16:33:59 https://gitlab.torproject.org/tpo/applications/team/-/wikis/Design-Documents/Bridge-URI-RFC 16:34:57 I'm starting the conversation with the projects I think will be interested (guard project, tails and onionshare) to see if we can agree on that RFC or on another format 16:35:16 if anybody is interested on being part of the conversation feel free to poke me to be included 16:35:39 any feedback there will be useful 16:36:05 yes, I would like to be included, but I might be passive until there is something I could help with 16:36:31 it should not be super difficult, as the bridge lines are in liner format itself 16:36:52 nice, I added you in CC in my email about it, I hope you got it 16:37:02 Yes, thanks 16:37:34 sure, it doesn't look dificult, but I'm not even sure who is consuming the existing QR codes or have their own URI format and how many things we are going to break 16:39:04 I don't have any more points in the agenda 16:39:07 we could make things work so long as there is a way to procedurally convert between qr codes and bridge lines 16:39:34 yes, that is the plan, to represent basically the same information 16:40:09 It was(and still is) a struggle to get share url for VMess working because V2Ray's configuration is in json format 16:40:48 :D 16:40:53 and each client trying to make a right balance between easy of implementation, human readable, and etc 16:41:10 and each of them end up with one of their own format... 16:41:32 anyway, nothing more from me on this topic 16:41:59 :) 16:42:10 great, I guess we can close the meeting 16:42:23 I'll wait for one extra minute just in case someone has something else 16:43:36 #endmeeting