Sprint Planning Meeting 2022 02 16

Sprint Planning Meeting, SecureDrop, 2022-02-16

Sprint timeframe: Mid-Day (PST) 2022-02-16 to Mid-Day (PST) 2022-03-02

1) Release check-in (i.e. previous sprint top priorities)

• SecureDrop Client 0.6.0 released on 2022-02-15, without source account deletion speedup. No user issues reported so far.

• SecureDrop Server release still scheduled for 2022-02-17, pending final testing today & tomorrow.

  • Mac Mini fixes
  • Security patches
  • ^ requires testing, see 2.2.0 test plan
  • Aiming for full kernel checks on supported hardware
  • Kev will test on NUC10, NUC11, 1Us, Mac Minis
  • Ro/Allie will aim to do kernel testing on NUC7/NUC8
  • Conor will sanity check ctime change on VMs
  • Conor/Kunal are following up on language coverage - another announcement sent today

2) SD Client release mini-retro

What's worked well:

• Vigorous QA! Lots of folks were involved in testing and comparing results +1 +1 (we have more of a team now to QA!!)
• I think Conor and I released an rc in under 15 minutes at one point, so the process is clearer now- it's still slower than what we used to do but safer +1 awesome job +1
• We identified a problem with weblate announcements (they weren't always resulting in emails, and now we know why)

What can be improved:

• we could use a release branch and avoid pausing main +1

• there's still a bit of tedium for package builds: bumping rc versions requires 3 PRs (component repo, packaging repo, lfs repo)

• Coordination between what's included in SDW and SD Server release; we squeezed ourselves a little bit by including changes in the server that required a release of the client first, ultimately having to back out of the changes on the client. (+1+1 (I think we probably should have waited before pulling in the api change, release the client first, then the breaking change+1)

• Stagger SDW and server releases, so timelines are more flexible +1 +1 +1 (also: same group of people doing QA, client release ongoing work meant that server QA was deprioritized)

  • Specifically, https://github.com/freedomofpress/securedrop/pull/6225 could have been put on hold until forwards-compatible support exists and has been released in SD Client
  • API versioning could help in cases like this +1+1 - may need SDK changes
  • maybe milestones or tagging can help us avoid this in future
  • Is it time to institute SD Client / SD Workstation release trains?

What's still a puzzle:

• Engagement with translators. How best to interface with Localization Lab? +1
  • [cfm] I think the next step (if not a complete answer) here is seeing how the continuous-translation workflow goes (and feels to us) once we go live with it for the Client.
• Working effectively with our schedules maybe (in terms of making release decisions when key stakeholders are OOO?) +1
• (Re urgency): A lot of urgent things feel like they are piling up along with other existing responsibilities. Are we being realistic about what we can get done when?
  • Speedy deletion
  • 4.1 Support
  • Debian Buster -> Bullseye
  • Reply/Queue stuff
  • ? (Export changes, reviewing Outreachy work, etc)
  • -1 SDW client contributor, -1 infra contributor for the next little while

3) Key dates and time commitments

• Erik and Conor alternating 48+PTO / 410, always off Fridays
• Conor @ 4*10 Mon-Thu
• Cory @ 4*10 Mon-Thu
• Allie @ 3*10 Mon-Wed
• Ro @ 4*8-10 Mon-Thu; Ro off 2022-02-17
• Giulio ~10-15 hours/week
• Gonzalo on break for ~2 months, then returning to 3*10 Mon-Wed schedule
• Maeve on break for ~1 month starting next week

2022-02-17   : SecureDrop Server 2.2.0 release
2022-02-21   : US/Canada holiday
2022-03-02   : Erik at Filecoin event
2022-03-03/04: Kunal moving (out), and likely a few days in the next week
2022-03-0(1|8): Meet-and-greet with Localization Lab to discuss collaboration

After sprint:

Early March: L10NLab chat
2022-03-08 : Tails 4.28
Late March?: SecureDrop 2.3.0

Vulnerabilities triage: Cory

4) Priorities for next sprint (proposed):

1. Implement lightweight spam mitigation measures in SD Server:

• tor2web detection to prevent clearnet bots and achieve search engine delisting
• hidden form field to mitigate bot behavior
• investigate additional mitigations that may have impact on human submitters

Rationale: Spam is an increasingly common problem for organizations managing SecureDrop instances, which may ultimately cause them to stop using SD altogether.

2. Get CSS cleanup & design standardization for Source Interface to "Ready for review"

Rationale: This is on the critical path for the "Flow inversion" design change, which is intended to address significant usability challenges with the current source experience.

3. Begin work on high priority fixes for SD Client:

   • Indicate that deletion is in progress until all data is removed from disk
     • This is now (again, after revert) true for Source Account deletion
     • This is currently not true for Conversation deletion
   • Speed up deletion as much as possible
   • Resolve issue with stale jobs being re-enqueued after user logs out / logs back in

Rationale: Speedy deletion is our #1 user story to address, and relates highly to the spam problem above. The "stale jobs" bug is a severe enough data integrity issue that it warrants high priority attention.