Skip to content

Sprint Planning Meeting 2020 06 24

Jump to bottom
Erik Moeller edited this page Jun 24, 2020 · 2 revisions

Sprint Planning Meeting, SecureDrop, June 24, 2020

Sprint timeframe: Beginning of Day (PDT) 2020-06-24 to Beginning of Day (PDT) 2020-07-08

0) Retrospective

What we said we would do:

  1. Release SecureDrop 1.4.0 (including keyring update, deletion fixes, sdconfig improvements)

Sprint goal met.

  1. Prepare SecureDrop Workstation keyring update and upload kernel update to staging

Sprint goal partially met.

  • Keyring update prepared and released, most users have updated.
  • New workstation kernel update in progress, new kernel now uploaded yet.
  1. Apply black code formatter & isort to client/proxy/SDK repos

Sprint goal met.

  • Proxy PR (black and isort) merged.
  • Workstation (black only) PR merged.
  • SDK (black and isort) PR merged.
  • Client PR (black and isort) merged.

Additional accomplishments

  • Fixed major crashers in the client - one that was encountered during the pilot
  • We now delete multiple source widgets within one sync in the client
  • Landed major CSS refactor in securedrop-client. CSS now lives in files, which should make style changes much less error-prone and easier to reason about.
  • Signficantly clarified and updated the release management documentation.
  • Landed community improvements to deletion checks: https://github.com/freedomofpress/securedrop/pull/5308

Other team comments

What went well:

  • It was nice to pair with Conor and to get a chance to work closely with him. Rotating roles really help us get to know people we don't normally work with. (Also helps with acation factor.)
  • Seems like a little more community participation, including a guest at standup, and an admin contributing a PR :)
  • Docs and process improvements had a quick turnaround, thanks to Allie meticulously tracking discussed points throughout the release

What could be improved:

  • Updating docs as part of release was confusing, same problem as with 1.3.0. Consensus seems to be 1) rename master -> docs, 2) force-push release branch to docs
  • SD core/classic/legacy test coverage could be improved, e.g. admin tests did not catch the "securedrop-admin install" validation problem in 1.4.0. That would have been caught with a v2-only QA matrix option, but shouldn't require manual testing. +1
    • Test plan for SD 1.4.0 could have caught the validation problem
  • It was nice getting contributions, but we also had to turn down at least one PR that hadn't aged well. The contributor was still game, which is awesome, but we could do better at managing community contributions. I know no one has a lot of time, but we should perhaps revisit the idea of a rotating community engagement role? Also expanding the pool via hackathons/online events would be worth trying.
  • Releases are still taking too long. It basically took all day on the actually release day. +1
    • Updating the builder container image alone takes several hours (including CI runs, backports), let's stop doing that +1 -> always run apt-get update & dist-upgrade in the containe.r But with some kind of snapshot system to capture build container used for releases?
  • I lost a lot of time trying to set up and troubleshooting my dev environment (Qubes).

Learning time debrief Kuahal (Rust): 1 byte can cause too much trouble: instead of the righting the actual full sdstatus in rust, I spent a lot of time figuring out why the rust code was sending out DNS queries for .onion addresses over normal network.

  • socks5://127.0.0.1:9050 -- means DNS over normal system, and then use socks proxy
  • socks5h://127.0.0.1:9050 means DNS is also on the proxy
    • https://trac.torproject.org/projects/tor/wiki/doc/TorifyHOWTO/Misc
      • "If you use just plain socks5 instead of socks5h, you will definitely leak DNS requests."
    • kushal, that is terribly interesting and i'd love to hear more! =)
    • for my part, i did NOT spend the time i had alloted on rust/sdstatus, willing to re-commit again for friday learning time

Erik: Instead of Molecule/Ansible, ended up spending time digging into Qt4 resize beavior. Still want to deepen that a bit more before shifting gears, as I'd like help maintain our dom0 GUI code. (Let's pair! ~Allie :)

Ro: Spent learning time mostly on Qubes staging environment setup troubleshooting. Some of this involved learning a bit more about molecule, but look forward(?) to more molecule/ansible learning soon.

Kev: revisited (briefly) cryptopals code from last iteration - had kickoff chat with folks about having another go at it using Rust.

1) Review key dates and time commitments

2020-06-24              : Regional Canadian holiday: Mickael
2020-06-25              : SecureDrop 1.4.1 Release
2020-06-30              : SecureDrop Release Keyring Expires
2020-07-01              : Canadian holiday: Mickael, Kev, Ro
2020-07-02 to 2020-07-03: FPF holidays (4th of July weekend)
2020-07-06              : John PTO

After this sprint:

2020-07-28              : SecureDrop 1.5.0 Release
                          Tails 4.9 Release

Time check: https://docs.google.com/spreadsheets/d/1pDGvReS8G-WzX9lRLBJk0RW_MQ9KXIUoPGe97VU9fGs/edit#gid=0

2) Review draft roadmap

https://docs.google.com/document/d/1cWFoOSBhKTmYZz6EtMRk3RUHlsAyKGbqdtTb-D71oG0/edit#

3) Agree upon top 3 priorities for the next two weeks (8 working days)

  • Release SecureDrop 1.4.1 with fix for configuration validation

    • Proposed release date: 6/25

    • Kev/Mickael RM and Deputy RM

  • QA SecureDrop Workstation releases for kernel update, updater improvement, client changes

    • Proposed release window: 7/14 to 7/15

  • Complete a first research spike to determine whether a server upgrade path 16.04->18.04->20.04 is feasible

Learning objectives

  • CryptoPals (John, Kevin, Allie, Mickael), Rust (Kushal, Conor), Qt4 (Erik), Ansible/Molecule (Ro)

4) Select and estimate tasks

https://docs.google.com/spreadsheets/d/16sp95h4wxgGu6YWMVQD9wLlWRiVSXG6HHlQz5a4m9QQ/edit#gid=0

Clone this wiki locally