Standup Notes 2018 09 13
Workstation call-outs:
- pulled process-download issues into current sprint (arguably part of the larger "unbreak master" story), bumped SDK for now
- sd-decrypt removal status? Should try to get that done this week if at all possible.
Participants (alphabetical): Conor, Emmanuel, Erik, Freddy, Jen, Kevin, Kushal, Mike, Mickael, Nina
Yesterday: Worked with Josh/Jen on workstation changes; working on sd-process-download bugfix
Today: Get PR up ^^
Blockers: none
Yesterday: Non-SD Work, moving forward on training with a client.
Today: Non-SD work, in prep for all staff. Also finalizing on scheduling training with a client.
Blockers: None
Nothing to escalate.
Reminder: PTO tomorrow
Yesterday: Fair bit of non-SD and SecureDrop.org issues organization/follow-up, incorporating some final changes into SecureDrop TM guidelines based on feedback
Today: Decision day for A-SRE hire, helping with a couple interviews there. Design review for workstation. Some other non-SD follow-up.
Blockers: None
Yesterday: Spent more time on SD remote QA
Today: More on ^^
Blockers: Not really blocked, need some of Mike's time
Yesterday: Did a round of review in the client repo. Made a small PR - checking for known vulns, adding static analysis. Reviewing and merging workstation stuff.
Today: Do another round of review in both repos
Blockers: None
Yesterday: Worked on small PR against tbb-0.9.0 branch, sorting out logging issues
Today: More on ^^
Blockers: None but one PR ready for review (DEBUG statements)
PTO
Yesterday: Forum migration fun!
Today: Just pushed a PR for discourse for the logging and backup story, DNS changes coming. Work with Freddy on remote server administration.
Blockers: None
Yesterday: Mostly working on sd-decrypt removal. Moved decryption logic into sd-svs. Issue with Python3 migration.
Today: ^^
Blockers: None
Yesterday: Submitted PR to address #6 (logging). Work on #5 (sync logic).
Today: Fixed up in light of feedback on logging PR #23. Continued to work on solution for #5 (sync). PR of sync imminent for discussion purposes.
Blockers: None. I'm not working on SD things tomorrow but will be online via chat.
Yesterday: Just finished prelim review of clickable wireframes @ UX mtg. Looking forward to getting more feedback.
Today:
Blockers:
Mickael: As it is now, I thought that having the files open in sd-svs would be better than using sd-journalist, given that sd-journalist would have Internet.
Multi-user discussion, see https://github.com/freedomofpress/securedrop-workstation/issues/145
Jen: A few problems with more than user, e.g., managing keys. Agree re: cost. Could do per-journalist USB drives -- avoid all the provisioning problems per-user. Consistent with Qubes own recommendations.
Conor/Mike: Performance issues?
Kevin: USB3 key on Dell XPS13 with 8G, performance was terrible.
Mickael: USB key performance varies dramatically.
Kevin: Could try with different USB keys, machine with more memory.
Jen: If we have all VMs between all users, key management issue. Might want to ask Qubes. Every user would have access to dom0.
Conor: Don't see issue with journalists having access to dom0. All journalists have access to SVS in Tails architecture, sharing it. Curious about technical limitations on per-key management. Need different vault VMs?
Jen: Would want each journalists to have their own set of VMs.
Erik: Could YubiKey be alternative?
Kushal: Would have to teach journalists. Applet where we click, attach/detach is buggy.
Conor: Could be reasonable solution.
Nina: Concern about security proliferation with large number of laptops.
Jen: If we put individual keys on YubiKeys, that does address the concern. Both using it and provisioning keys from admin perspective is not a great story.
Kev: You could have a script running in dom0.
Nina: How could UX be improved?
Conor: What are we willing to store w/ private key, where to store it?
Mickael: Provisioning is hard. Probably can't get around having a Tails VM somewhere safe, key backups.
Kushal: Doing this will increase timeline for project.
Jen: Threat model, considering what a journalist will have access to with regard to another journalist's information. Right now everything is stored unencrypted. In a world where multiple journalists have access to sd-svs VM that's not okay.
Mickael: Any mistake a journo makes will compromise every single submission. Any misconfiguration on machine that's not air-gapped could increase exposure of data.
Conor: With Tails all sorts of ways data could be exposed. Must mitigate against mistakes but decrypt.
Jen: Just flagging that reason we talked about per-journalist keys is that there could be truly private messages for specific journos. That does imply that there should be meaningful.
Mickael: Everything around how we manage qubes RPC permissions might be an area where we'd want to have more robustness.
Actions:
-
Threat model analysis
-
Permissions analysis. Have to make sure that state of files is consistent across updates.
-
Contact Qubes team for advice: Erik to draft email
-
More testing of USB performance
Full recap here: https://github.com/freedomofpress/securedrop-workstation/issues/145