17:00:16 <hellais> #startmeeting OONI dev gathering 2016-07-11
17:00:16 <MeetBot> Meeting started Mon Jul 11 17:00:16 2016 UTC.  The chair is hellais. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:00:16 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
17:00:22 <hellais> so here we go again!
17:00:25 <hellais> who is here?
17:00:31 * hodgepodge waves
17:00:31 <landers2> here
17:01:19 <agrabeli> hi
17:01:52 <sbs> ehlo
17:02:46 <hellais> cool
17:02:51 <hellais> so let's get started with this
17:03:57 <hellais> I put down some things that are quite specific and having irl's input on them would be ideal since it requires debian specific knowledge
17:04:12 <hellais> if you have something else to discuss please do bring it up
17:04:31 <hellais> #topic How to package a web UI inside of debian
17:05:42 <hellais> So the idea with the web UI is that the dependencies are going to be managed using webpack, that will then take care of bundling them all together and spitting out a HTML, CSS, JS blob containing all the OONI web UI app code + the dependencies of it.
17:06:20 <hellais> I am not sure how the debian packaging system works and if they are ok with just shipping the already built HTML/JS blobs or if they want to be able to build them themselves from source
17:09:47 <hellais> I think this is something that would be useful to have irl input on so unless somebody has something to add to this I would just leave it here for backlogs sake and move onto the next item
17:09:47 <sbs> hellais: if not, would it be acceptable to download it like we download other ooni resources?
17:10:17 <sbs> perhaps this is even better because ti allows to update the UI independently of ooni-probe
17:10:47 <hellais> sbs: hum, that is an interesting idea. Though I would like much stricter validation on code than that currently present for downloading ooniresources
17:11:41 <sbs> hellais: right, I guess ooni has enough dependencies to verify digital signature of a download, isnt?
17:12:14 <sbs> (but admittedly that's a plan B proposal not a plan A proposal)
17:12:39 <hellais> sbs: yes we do actually. In theory that could be done. If debian doesn't want to ship it that could be a way of doing it, but I find it a bit of a messy solution to be honest.
17:14:34 <sbs> yes, standard shipping with debian would be easier for us
17:14:39 <sbs> less things tat can go wrong
17:14:42 <sbs> * that
17:15:55 <hellais> sbs: yeah, your suggestion I think is a good plan B approach, we should take note of this and depending on what irl or other debian people tell us we can go for that or not
17:16:03 <hellais> let's move onto the next item
17:16:18 <hellais> #topic How to handle the update of configuration files
17:17:20 <hellais> so the latest release of ooniprobe includes a terrible hack to ship updates of the configuration files for people that had already installed it in lepidopter (adjusting the concurrency to something more sane)
17:17:42 <hellais> in the future there should be a better way of doing this and I think again irl will look into how to do this the debian way based on:
17:17:56 <hellais> https://www.debian.org/doc/manuals/maint-guide/dother.en.html#conffiles
17:18:47 <hellais> again this is something that doesn't require that much discussion I think, but just wanted to put this out there so that if you have heavily customized your configuration for ooniprobe on lepidopter you are aware of the fact that it will be rewritten when it updates
17:19:04 <hellais> (the update should happen automatically this sunday so you have 1 week to backup your config file)
17:19:49 <hellais> in case you are wondering what the terrible hack is, here it is: https://github.com/TheTorProject/ooni-probe/blob/master/setup.py#L199
17:21:53 <sbs> hmm
17:22:20 <sbs> would it make sense for ooni probe to have a default-override configuration when the user changes a file with overrides
17:22:25 <sbs> and we ship the default?
17:22:36 <sbs> in such cases would this help?
17:22:44 <sbs> or I am missing the core of the problem?
17:23:29 <sbs> (I am thinking for example at OpenBSD where you typically modify /etc/rc.conf.local and the maintainers of the system update /etc/rc.local)
17:23:37 <sbs> * /etc/rc.local
17:23:47 <sbs> * /etc/rc.conf # This time it's correct
17:25:52 <hellais> sbs: yeah I think that approach would be better than the current one. We could have a set of defaults that are not even inside of a file and ship a config file for ooniprobe that has everything commented out except the lines that actually need to be explicited for the given platform (such a file locations).
17:33:15 <hellais> well this is what I had to bring up
17:33:16 <hellais> #topic misc
17:33:28 <hellais> do people have anything they would like to discuss, comment on?
17:36:00 <hodgepodge> I'd like to bring up a couple of miscellaneous topics that came up while I was at a security research event in Toronto a couple of weeks ago.
17:36:55 <hellais> hodgepodge: ah cool! please do!
17:37:07 <hodgepodge> In the event that a researcher would like to learn more about OONI, should you also let them know about the partnership program? They were mainly curious about how to integrate some post-quantum crypto tests into the Tor ecosystem.
17:37:27 <hodgepodge> I let them know what OONI was working on, but I wasn't sure where to direct them.
17:37:41 <hodgepodge> Since PQC is't really related to OONI's goal.
17:38:41 <hellais> hum that is interesting. What particular post-quantum crypto tests are they thinking about?
17:39:21 <hellais> Are these network related tests that would benefit from having distributed vantage points checking for them?
17:39:38 <hellais> that is are they looking for network attacks that would be carried out by a state actor?
17:40:09 <hodgepodge> I'm not entirely sure, to be honest. I believe that the researcher's principle research areas were centered around PQC key exchange protocols (so they'd probably want to talk to someone on the Tor browser team). Generally speaking, where should we point requests from academic researchers in that space?
17:42:27 <hellais> hodgepodge: probably the best thing would be to write an email to tor-dev about it, if it's ok to make this public. Otherwise tor-team.
17:44:40 <hodgepodge> Awesome, thanks! The other question that I had was centred around using some of the data that OONI has collected.
17:44:54 <hodgepodge> In a few weeks I'm going to be providing an overview of how to build scalable data pipelines with Luigi, and was wondering if I could talk about how the data pipeline that I worked on last year. The talk is going to be conducted at my college with a group of graduating infosec students as the audience.
17:46:21 <hellais> hodgepodge: that's great! Of course and if you can it would be cool if you could also share the slides once you have done the presentation
17:47:18 <hodgepodge> For sure!
17:48:02 <hellais> are there any more things people would like to talk about, share?
17:54:39 <sbs> not from me
17:54:48 <hellais> ok well I guess we can end this some minutes ahead of schedule
17:54:59 <hellais> thank you all for attending, have fun!
17:55:01 <hellais> #endmeeting