17:59:30 <phw> #startmeeting anti-censorship meeting
17:59:30 <MeetBot> Meeting started Thu Mar 26 17:59:30 2020 UTC.  The chair is phw. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:59:30 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
17:59:37 <phw> here's our pad: https://pad.riseup.net/p/tor-anti-censorship-keep
17:59:49 <arma2> cohosh: the turbo tunnel quic has this other weird feature where i send more and more bytes, as the failures pile up. until finally it all unwedged and i send a huge pile of backed-up bytes towards the bridge.
18:00:03 <phw> first of all, thanks to whoever adds helpful context to my poorly phrased discussion items
18:00:50 <dcf1> arma2: that's a known thing that I'm not planning to fix until after the turbotunnel merge. current snowflake has some best-effort buffering that meant to bridge between two proxies but didn't really work.
18:01:01 <phw> cohosh: i stumbled upon #29863 while doing roadmap maintenance. do you happen to know its status?
18:01:11 <cohosh> uhh
18:01:30 <cohosh> i haven't thought about this in awhile
18:01:57 <cohosh> extra monitoring is probably a good idea, but this was before gman's thing was deployed
18:02:00 <arma2> dcf1: cool. yeah, it doesn't seem critical-path-to-minimum-viable-snowflake
18:02:19 <phw> ok, gotcha
18:03:02 <cohosh> i'm open to thinking about it more, and think we're not in the most comfortable place with automatic monitoring of snowflake
18:03:08 <cohosh> but it needs more thought
18:03:20 <cohosh> and is lower priority now that we know when it's unreachable
18:03:25 <phw> ok, i'll remove the merge_ready then
18:03:42 <cohosh> ok
18:04:20 <cohosh> for the next one #29274, that was filed my first week and is definitely way too vague
18:04:26 <phw> i was also curious about #29274. did we succeed in that already? or is it a perpetual reminder that we should dogfood?
18:04:29 <cohosh> i think it's safe to close it
18:04:40 <cohosh> yes it is a perpetual reminder to dog food
18:04:59 <phw> we can send a link to this ticket to whoever isn't using an alpha PT right now
18:05:43 <phw> i'll close the ticket, then
18:05:51 <phw> that's it for our discussion items today
18:06:16 <cohosh> oh i have another quick question
18:06:40 <cohosh> is everyone okay with snowflake-webext for the name of the second snowflake repo?
18:07:00 <cohosh> i made #33740
18:07:22 <dcf1> yes
18:07:33 * phw nods
18:07:43 <cohosh> cool
18:07:46 <arlolra> sure
18:08:59 <cohosh> alright that's it from me
18:08:59 <phw> let's move on to our "needs help with" sections
18:09:21 <phw> cohosh: do you mind taking a look at my revisions for #30941?
18:09:35 <cohosh> yep i can do that
18:09:37 <phw> arlolra has #19026
18:09:39 <phw> thanks!
18:09:48 <cohosh> i can also review that
18:10:08 <phw> thymbahutymba has a question related to multi-arch docker. are you around, thymbahutymba?
18:10:21 <thymbahutymba> yes
18:11:25 <thymbahutymba> I wrote the script for start the testing and eventually proceed with the release of the new image once is detected that the version of the docker image is less than the deb packages.
18:12:14 <phw> this is about continuous integration of changes to the docker file, right?
18:12:49 <thymbahutymba> To keep it short my question is: there is no guarantee that the tor version is the same for each architecture arm, arm64 and amd64, what should happen if one of them is not changed, should be released only the two that have different version on tor? (sorry for my bad english)
18:14:26 <thymbahutymba> because I was thinking to use the manifest features of docker for tag all latest docker images so no matter which is you architecture you will pull the correct images.
18:14:33 <phw> why is there no such guarantee? is it because debian packages for different architectures don't all have the same version?
18:15:41 <thymbahutymba> I don't know that, some guys in tor-dev channel told me that I should not suppose that the tor version are in sync for each architecture
18:16:07 <thymbahutymba> I'm extracting the latest version of tor from the Release file on https://deb.torproject.org/torproject.org/dists/stable/main/binary-ARCH
18:16:53 <thymbahutymba> So far I saw them always in sync
18:17:48 <phw> oh, i see. i think differing tor versions aren't a problem as long as no version is heavily outdated. for example, see #32672
18:18:41 <phw> it may also be helpful for your script to scream once the versions aren't in sync. we can then decide how to proceed.
18:18:44 <phw> does that make sense?
18:20:35 <phw> shall we continue this discussion in #tor-dev?
18:20:51 <phw> anything else for today? if not, i'll end the meeting in a minute
18:20:56 <thymbahutymba> Yes and not, because the final result that I would achieve is to have some cron/systemd-timer that each day will check the version and if new tor version were released proceed with CI/CD. But this can be solved in a different way, how the images should be tagged. obfs4-bridge:ARCH-TOR_VERSION?
18:21:09 <thymbahutymba> oh yes fine :)
18:21:15 <dcf1> Just noticed there's discussion today in #ooni about a reported TLS MITM of GitHub Pages in China.
18:21:21 <dcf1> https://info.williamlong.info/2020/03/github-pages.html
18:21:24 <cohosh> woah
18:21:27 <dcf1> https://www.v2ex.com/t/656367
18:21:32 <dcf1> https://gist.github.com/tomac4t/396930caa8c32f97c80afd9567b4e704
18:21:43 <dcf1> Haven't looked into it, just dropping some links from there.
18:22:05 <cjb> hi folks! is the reading group happening during this meeting next week, or at another time?
18:22:51 <phw> cjb: hi! the reading group will happen after next week's meeting
18:23:33 <cjb> great.  is it okay for me to invite a coworker too?  (I'm not sure whether they'll want to join yet.)
18:23:37 <phw> we figured we would allocate 15 more minutes for the meeting, just in case we need it. if this turns out to be a poor plan, we will do things differently next time
18:23:51 <cjb> sounds good
18:23:57 <phw> yes, bring your coworker :)
18:24:22 <cjb> dcf1: just curious, does it look like the github pages response was altered?
18:25:11 <juggy> For the Salmon project, there needs to be some way of persisting data about different users; however, how would we identify users? Salmon suggests custom salmon account emails + FB account registration, but this seems difficult to implement into the HTTPS distributor where users simply request for bridges then leave.
18:25:32 <cohosh> juggy: we can continue this in #tor-dev
18:25:38 <dcf1> cjb: i don't know
18:25:42 <juggy> ok!
18:25:45 <cohosh> but we wouldn't be implementing it exactly as the paper says
18:25:54 <cohosh> and definitely not using facebook
18:27:06 <phw> hey juggy, if you wanna participate in anti-censorship meetings regularly (and i think you should!), you can add yourself to our meeting pad: https://pad.riseup.net/p/tor-anti-censorship-keep
18:27:19 <phw> we use it to update each other on our progress and what we need help with
18:28:23 <phw> i'll wrap up the meeting in a minute if there's nothing else
18:29:44 <phw> #endmeeting