Skip to content

Sprint Planning Meeting 2021 05 05

Jump to bottom
Erik Moeller edited this page May 5, 2021 · 1 revision

Sprint Planning Meeting, SecureDrop, 2021-05-05

Sprint timeframe: Beginning of Day (PDT) 2021-05-05 to Beginning of Day (PDT) 2021-05-19

1) Retrospective

What we said we would do:

  1. Complete first iteration of Safe Deletion for SecureDrop Client (ready for review status)

Goal not met. Frontend work is mostly done, using existing pending state; backend/server-side changes pending. Final UI for pending state pending.

  1. Revise SecureDrop threat model based on auditor recommendations

Goal not met.

  1. Remove Ubuntu 16.04 and v2 onion service support from SecureDrop Core

Goal fully met. SD core code removal completed & most of docs updated.

Note: Team velocity impacted by unplanned fixes (see below) and sickness/time off.

Additional accomplishments

  • Overall,through docs & support, helped >40 SecureDrop instances with migration to Ubuntu 20.04, including discovery and resolution of new technical issues

    • Major onion service ecosystem shift to v3, ahead of the removal of v2 onion service support from Tor - improving security & privacy for journalists and sources

  • Added several new onion names, which are proving quite popular

    • Anecdotally, onion names seem to also act as an incentive for folks to submit their instance to the SecureDrop directory

  • Developed unofficial procedure to assist with remote updates

  • Expanded black/isort usage in SecureDrop Client repo

  • Made significant improvements to test stability in SecureDrop Client repo

Related to Ubuntu 20.04 migration

What worked well:

  • Dozens of instances migrated, with full reinstall, despite travel restrictions.

  • Clear comms within the team: frequent updates with data dashboards, active scheduling of calls to walk orgs through the necessary steps

    • Big thanks to Ro for maintaining that data dashboard!

  • Lots of new v3s! More onion names! +1 These are successes for Tor at large, not just for SecureDrop

  • Continuous improvements to migration tooling in response to specific admin requests and issues encountered. Point release seems to have helped. +1

    • Especially ssh onion service from backups

    +1, the positive inclination toward point releases really helped ship changes

  • consistent communications with instances

    • surprisingly (to me) positive vibes from news orgs, given the logistical difficulties and tight timeline. edit: should be noted I did miss some feedback. :^( +1

  • Trying to get feedback early on from instances ("Are you aware of the migration") without asking them for anything more demanding was a good way of seeing who was responsive on the Support portal +1 +1

  • migrating the higher-support-need instances early

  • BTW, lots of folks complimented us on our docs

  • \m/ <3 =)

What can be improved:

  • Technical problems on the support portal, email delivery broke for nearly a week, which set back comms +1

  • having a remote upgrade process would have been really really beneficial+1+1+1

    • Some of this may have been prioritization: We made significant improvements like unattended-upgrades, which perhaps should have been prioritized lower than remote upgrades. +1

  • supporting 20.04 at least 3 months earlier would have helped folks with the transition, which was sudden +1+1

    • Little focal-only changes/improvements we were able to fit in, due to other commitments

    • hardware upgrade should have been pushed further--some instances did it, but some are on ubuntu 20.04 on eol hardware

  • some folks are very fed up with some of the 'clunkier' aspects of SecureDrop (Tails upgrade, expired signing keys, upgrade requiring reinstall, large backup file sizes, etc) +1 (would love to hear more detail separately+1)

    • Action: Docs more accessible/organized/shortened

  • Tails website went down on April 30th (not our fault but yeah)

  • icinga transition at the same time as migration deadline was mildly stressful; ditto with redmine struggles/notification issues (hard to mitigate but relevant)

What's still a puzzle:

  • How to reduce our dependency on the server OS, to make upgrades less painful.+1

    • Better test coverage

  • How to simplify/automate remote administration, upgrades.+1+1+1

  • Monitor server configuration is challenging to maintain effectively (+1, and if it's not working correctly we rely on admins to notice and self-report...)

  • Admins really preferred using Signal (puzzle: what's the best and most effective way to provide support?)

    • The priority/non-priority distinction may be a useful way to decide when to offer that option. +1

Everything else

Learning time debrief

  • (Conor) Tinkering a bit more with Rust!
  • (Erik) As part of login PR, was able to read a bit more client networking code

2) Review key dates and time commitments

2021-05-11              : SecureDrop 1.8.2 point release
2021-05-07              : Time off: Erik, Mickael
2021-05-14              : Time off: Conor
2021-05-25              : fedora-32 EOL
2021-06-01              : Tails 4.19 (UX changes to Tor integration)
2021-06-08              : SecureDrop 2.0.0 release
(TBD)                   : Time off: Kushal

After sprint:

2021-05-21              : @emkll last day :(
2021-05-24 to 2021-05-28: Time off: Ro
2021-06-21-25           : Time off: Conor (~1 week)
2021-06-30              : SecureDrop release key expires

3) Agree upon top 3 priorities for the next two weeks

  1. Complete first iteration of Safe Deletion for SecureDrop Client (ready for review status)

  2. Complete deliverables for SecureDrop 1.8.2, test them, and issue a point release

  3. Update TemplateVMs to Fedora 33

4) Select and estimate tasks

https://docs.google.com/spreadsheets/d/14HhX572bwsuSQ1EKRPSkMM1G9ofPQ5RTvajjhrNNXgE/edit#gid=0

Clone this wiki locally