-
Notifications
You must be signed in to change notification settings - Fork 685
Sprint Planning Meeting 2020 09 03
What we said we would do:
- Ubuntu 20.04 transition: Get Focal packages to build successfully, then set up
make staging-focal target
Sprint goal partially met:
- Package build PR close to landing
- Work on staging target in progress.
- Seen/unseen: Scope and begin implementing server-side changes, with an eye to merging all changes required for a read/unread MVP before the September 8 feature freeze.
Sprint goal partially met:
- Client & server-side scoping complete; high-level spec agreed upon
- Implementation of server-side changes has not started yet.
- Template consolidation: Begin phase 1 of implementation (creating the preconditions for consolidation).
- Further threat modeling and analysis re: MIME type handling
- Create symlinks for mimetype association in private volume
- Move securedrop-proxy configuration files to /home/user
Sprint goal partially met:
- PRs for packaging & symlinking appropriate MIME type settings in private volume are under review.
- Threat modeling & securedrop-proxy changes still pending.
Additional accomplishments
- Joan's first PR was successfully merged :)
- Both John and Mickael have completed very informative spikes on Qubes 4.1
- Threat model knowledge sharing sessions with multiple SecureDrop team members
- Responded to setuptools breakage in a timely fashion :/
- SecureDrop Workstation: Landed PR that will hopefully resolve issue with u2mfn kernel module sometimes not being built correctly, which caused VMs to sometimes break after a kernel upgrade.
- improved docs and reproducibility of test data generation (e.g., cassettes)
Other team comments
What worked well:
- Collaborative fixes on packaging, both for focal effort & setuptools fixes +1
- Continued adherence to highly organized epics, e.g. template consolidation, ongoing seen/unseen changes, focal transition
What can be improved:
-
(Erik) setuptools breakage: Can we make SecureDrop more resilient against such upstream breakage? https://xkcd.com/2347/ explains
- (Conor) +1. +3 Many of the critical tools we depend on (e.g. dh-virtualenv) were pulling the very latest version by default. Let's try to pin judiciously absolutely everywhere, and file issues/PRs upstream if we find a place where it's not possible.
- (Kushal) using our own python package index for everything would minimize this kind of breakage. (but also introduce a lot of maintenance work?)- Yes, maintaince but provides better security too (not only stopping random breakage). I also mehntioned the security researcher's comment on the same (how we are mitigating many attacks they successfully did within companies). The comment from the security researcher about how to manage/build python dependencies
loved your talk! great advice for devs in there, and it is sort of related to my research. I think that properly checking hashes would completely mitigate my attack -- but nobody really does it all the time in the real corporate world
- We're already duplicating a lot of the Python packaging ecosystem—doing more of that is a significant commitment, would prefer to focus on reproducibility and pinning rather than re-hosting
- We're exploring --no-download option for older version of virtualenv, and --setuptools option for later version of virtualenv, to ensure we use a predictable version of setuptools
-
(Erik) Major sprint commitments still WIP, but also more PTO than planned + the above major distraction. This is a finish-up sprint.
-
(Allie) Documentation around Qubes errors and reporting of upstream Qubes bugs. There's not a lot of help on the internet so I think this is a big area for improvement. The issue I'm dealing with around the qrexec_daemon not starting is an example of something I would like to document once I find a solution.
- Conor: Good point. I've found lurking on the qubes-users & qubes-devel listservs to be highly informative. There's also a new community forum: https://qubes-os.discourse.group/ - And for live help IRC is the best #qubes on Freenode.
- We have an internal GDoc "Qubes 4 HELLA N00bs", maybe port that to SDW wiki for better discoverability
- (Allie) A historical doc on solutions we've found for previous bugs would be super helpful.
- (ACTION) Let's add more notes to https://github.com/freedomofpress/securedrop-workstation/wiki/Developer-Tips and other wiki pages, every time we resolve an issue
What's still a puzzle:
- (mickael) large changes to workstation provisioning are very complex and hard to test, due to configuration managed by salt and also packages
- Open Source projects work by pure luck and work of a few selected people. X)
Learning time debrief
(Erik) Didn't really use LT for it, but made progress on Qt PR for securedrop-client and should have something up later today.
(Conor) More poking at reproducibility of Python code -> .deb & .rpm files, down to <1% variability. Kushal mentions that "rpm" >f28 helps a lot with reproducibility
(kev) Did some Rust+Cryptopals during PTO quiet time (block cipher challenges)
(John) Learned about the press freedom tracker workflow, started looking into how some of that could be automated.
(kushal) Wrote code to analyze network behavior. Studying Bulletproof SSL book to understand better.
(mickael) defcon video from appsec village: https://www.youtube.com/watch?v=cD3-1rb_HNM some interesting new owasp tools for threat modelling and security checks
(Allie) PTO on learning day so nothing to report
Until 2020-09-14 : Ro on personal leave
2020-09-04 : PTO: Mickael
2020-09-04 : Virtual conference: Kushal
2020-09-07 : FPF holiday / Labour Day
1 day PTO: John
After Sprint Period:
2020-09-22 : SecureDrop 1.6.0 QA Begins [revised date]
2020-09-25 : FPF Holiday
2020-10-06 : SecureDrop 1.6.0 Release [revised date]
- Template consolidation
- Complete consolidation of MIME type handling
- Spike: Create a working branch & draft PR with small/large template provisioning logic (scoped to creation of the templates only, side-by-side with existing templates, we can record/open issues for any unforseen followup)
- Stretch goal / potentially defer: Move securedrop-proxy configuration to /home/user
- Seen/unseen
Complete server-side requirements in preparation for 1.6.0 release:
- Migration to new architecture: https://github.com/freedomofpress/securedrop/issues/5474
- New API endpoints: https://github.com/freedomofpress/securedrop/issues/5475
- Ubuntu 20.04 transition
- Provide tor, linux kernel, ossec, and securedrop packages for Focal via apt-test
-
make fetch-tor-debs
to pull both Xenial and Focal tor debs - Land initial work on packaging and
make staging-focal
target
https://docs.google.com/spreadsheets/d/1GSgXuc3AEEwNVXqQHcvcjj6vbBT9g5_YJAa-RwF-Nzg/edit#gid=0