16:00:03 <meskio[mds]> #startmeeting tor anti-censorship meeting
16:00:03 <MeetBot> Meeting started Thu Mar 12 16:00:03 2026 UTC.  The chair is meskio[mds]. Information about MeetBot at https://wiki.debian.org/MeetBot.
16:00:03 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
16:00:06 <meskio[mds]> hi everyone!!
16:00:08 <meskio[mds]> here is our meeting pad: https://pad.riseup.net/p/r.9574e996bb9c0266213d38b91b56c469
16:00:08 <meskio[mds]> ask me in private to give you the link of the pad to be able to edit it if you don't have it
16:00:08 <meskio[mds]> I'll wait few minutes for everybody to add you've been working on and put items on the agenda
16:00:18 <cohosh> hi
16:01:29 <Shelikhoo[mds]> hi~hi~
16:01:32 <meskio[mds]> let's start with the announcements while people finish updating the pad
16:01:49 <meskio[mds]> We can bump the min Go version in snowflake and lyrebird to 1.25 if needed
16:02:12 <Shelikhoo[mds]> nice~ hehe
16:02:52 <cohosh> yeah, no discussion needed really but once https://gitlab.torproject.org/tpo/applications/tor-browser-build/-/merge_requests/1447 is merged we can remove the utls backport from lyrebird and update snowflake :)
16:03:15 <gaba> hi
16:03:56 <meskio[mds]> in the past we've been looking into what is in debian as a reference of what version of go is  easy for people to have
16:03:57 <meskio[mds]> debian stable has go 1.24
16:03:57 <meskio[mds]> you need debian sid for go > 1.24
16:04:31 <cohosh> okay, the latest utls release needs a min version of 1.24
16:04:48 <Shelikhoo[mds]> for my own development environment, I usually just try to use to most recent version of it
16:04:51 <cohosh> so 1.24 seems like a reasonable min version for us to maintain
16:05:12 <cohosh> Shelikhoo[mds]: yeah same here, but you can use the latest version even if the min supported version is lower
16:05:13 <meskio[mds]> yes, maybe something to maintain if is easy, but not a hard limit :)
16:05:34 <meskio[mds]> I've been using debian's go, but I can update if needed
16:06:02 <meskio[mds]> I guess we can move to the discussion
16:06:26 <meskio[mds]> there are two topics from last week, but as I know there is work done on them I'll raise them to see if we have anything to discuss on those topics
16:06:39 <meskio[mds]> Should we priorize better matching logic on snowflake broker
16:06:56 <meskio[mds]> anything to talk about this? or should we move on?
16:07:37 <Shelikhoo[mds]> nothing to report on this for now
16:08:04 <meskio[mds]> ok, we can move on
16:08:07 <meskio[mds]> proposal to get a separate domain name for bridge reachability tests
16:08:18 <meskio[mds]> same? anything to discuss?
16:08:23 <Shelikhoo[mds]> EOF
16:08:43 <cohosh> same with this, nothing new there
16:09:03 <meskio[mds]> ok, let's go to the new topics
16:09:09 <meskio[mds]> should we start collecting webtunnel bridges for the missing pools (email and restricted)
16:09:23 <meskio[mds]> I added this one, as there is a request from Tails to distribute webtunnel bridges over email
16:09:47 <meskio[mds]> the only distributors without webtunnel bridges are email and reserved
16:10:08 <meskio[mds]> we've rolled distributors one by one so we could have enought bridges for each of them
16:10:28 <Shelikhoo[mds]> what is "restricted" channel?
16:10:37 <Shelikhoo[mds]> any quick reference?
16:10:52 <meskio[mds]> restricted is not really a distributor, we keep bridges on reserve to be used for testing or any other purposes
16:11:04 <Shelikhoo[mds]> okay
16:11:06 <Shelikhoo[mds]> thanks
16:11:08 <meskio[mds]> there are few bridges on that pool
16:11:15 <meskio[mds]> and in reality we barely use them
16:12:03 <meskio[mds]> my proposal is to enable the rest of the pools in rdsys, but don't enable the distribution over email until we have enough bridges
16:12:04 <Shelikhoo[mds]> I don't have too much opinion on this topic
16:12:10 <meskio[mds]> so new bridges slowly get assigned to them
16:12:53 <cohosh> sounds good to me
16:12:55 <meskio[mds]> that will take some time, but I don't think we need email really fast
16:13:03 <meskio[mds]> with this we'll have webtunnel on parity with obfs4
16:13:16 <Shelikhoo[mds]> yes, sounds good to me
16:13:22 <cohosh> operators can manually choose which pool they want to be in
16:13:27 <Shelikhoo[mds]> nice!
16:13:28 <meskio[mds]> good, I'll do the config changes
16:13:37 <cohosh> so if there's a webtunnel bridge operator they could still decide to be in the email pool?
16:13:50 <meskio[mds]> yes, they can
16:14:06 <meskio[mds]> actually many did for telegram, as we asked them so we could get bridges faster on that distributor
16:14:19 <cohosh> okay cool
16:14:26 <cohosh> yeah this sounds good
16:14:34 <meskio[mds]> I did check and there are few (was it 2?) webtunnel bridges configured for email
16:14:41 <meskio[mds]> an those are not been distributed currently
16:15:26 <meskio[mds]> ok, let's move to the last topic
16:15:29 <meskio[mds]> New stun servers being added, any policy issue with these servers?
16:15:58 <Shelikhoo[mds]> yes!
16:16:43 <Shelikhoo[mds]> so basiclly there are 4 new stun servers I found working correctly, and is considering to add them to snowflake config
16:16:49 <Shelikhoo[mds]> to replace 3 servers that are not working correctly
16:17:19 <Shelikhoo[mds]> this is one of the low hanging fruit from the nat type matching system research
16:18:10 <Shelikhoo[mds]> these 4 servers are working from a technological point of view, and I would like to know if any of them are not working for us due to policy issue
16:18:42 <Shelikhoo[mds]> that such they have previously asked us not to be included
16:18:46 <Shelikhoo[mds]> such as they have previously asked us not to be included
16:19:12 <Shelikhoo[mds]> if not we can go ahead and proceed with the change
16:19:37 <cohosh> we haven't been in contact with any that you're proposing on that ticket
16:20:30 <meskio[mds]> I guess we can just use them and see if there are any complains, but if any is clearly run by a volunteer maybe is good to ask
16:21:55 <meskio[mds]> is great that one is a .ru, I hope that means working better in russia
16:23:11 <Shelikhoo[mds]> From a plain sight, these servers are from enterprise entity
16:23:11 <Shelikhoo[mds]> stun.telnyx.com:3478
16:23:11 <Shelikhoo[mds]> stun.hot-chilli.net:3478
16:23:25 <Shelikhoo[mds]> for the other two; I am not so sure
16:24:27 <meskio[mds]> might make sense to add some stun tests to our vantage points, but I guess is not very high priority
16:24:56 <Shelikhoo[mds]> yeah... in theory we could do that
16:24:56 <Shelikhoo[mds]> BTW
16:25:03 <Shelikhoo[mds]> these 4 server is not found on ooni
16:25:20 <Shelikhoo[mds]> so their test are done on vantage point manually
16:25:32 <meskio[mds]> ahh, true ooni has stun test, maybe we don't need to add them to our vantage point but to ooni
16:26:08 <Shelikhoo[mds]> meskio[mds]: I hope so one say why my snowflake is connecting to russian domains. -> https://lists.archlinux.org/pipermail/arch-mirrors/2017-July/000684.html
16:26:50 <Shelikhoo[mds]> s/so/no/
16:26:50 <Shelikhoo[mds]> I hope no one say why my snowflake is connecting to russian domains. -> https://lists.archlinux.org/pipermail/arch-mirrors/2017-July/000684.html
16:27:35 <Shelikhoo[mds]> but anyway I think if there is no reason to object, we can proceed with changing our circumvention setting, and see if anyone complains
16:27:53 <Shelikhoo[mds]> if not we can proceed with edit the bridgeline in tor browser
16:28:12 <meskio[mds]> sounds good to me
16:28:37 <Shelikhoo[mds]> EOF from me on this topic
16:29:00 <meskio[mds]> any other discussion topics?
16:30:01 <meskio[mds]> nice blogpost in the interesting links about NAT types: https://tailscale.com/blog/how-nat-traversal-works
16:30:13 <meskio[mds]> I need to read it carefully, my NAT knowledge is not that great
16:30:20 <meskio[mds]> I guess we are done for today
16:30:43 <meskio[mds]> I'll end the meeting here
16:30:43 <Shelikhoo[mds]> yes, EOF from me
16:30:43 <meskio[mds]> #endmeeting