Skip to content

Standup Notes 2018 09 13

Erik Moeller edited this page Sep 14, 2018 · 1 revision

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

Conor

Yesterday: Worked with Josh/Jen on workstation changes; working on sd-process-download bugfix

Today: Get PR up ^^

Blockers: none

Emmanuel

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.

Erik

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

Freddy

Yesterday: Spent more time on SD remote QA

Today: More on ^^

Blockers: Not really blocked, need some of Mike's time

Jen

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

Kevin

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)

Kushal

PTO

Mike

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

Mickael

Yesterday: Mostly working on sd-decrypt removal. Moved decryption logic into sd-svs. Issue with Python3 migration.

Today: ^^

Blockers: None

Nicholas

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.

Nina

Yesterday: Just finished prelim review of clickable wireframes @ UX mtg. Looking forward to getting more feedback.

Today:

Blockers:

Extended discussion

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

Clone this wiki locally