Sprint Planning Meeting 2022 02 16
-
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
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
- 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
- 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.
- 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.
-
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
- Indicate that deletion is in progress until all data is removed from disk
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.