-
Notifications
You must be signed in to change notification settings - Fork 686
Standup Notes 2019 01 24
- garbled ncurses based UI while upgrading trusty systems - see https://github.com/freedomofpress/securedrop/issues/3965 -- might be network connectivity / tmux interaction? advise users about it in docs
Yesterday:
- Working on build logic -- Mickael/I collaborated on it
Today:
- Priority is point release
- Will push testing tags to xenial in container registry
Blockers:
None
Yesterday: Messaging and outreach, non-SD work
Today: Followup from outreach, non-SD work
Blockers: None
Yesterday:
- Sprint planning and associated follow-up
- Prepared & distributed messaging for upcoming Xenial transition
- Revised advisory for stuck 0.10.0 instances to account for apt vulnerability & notified them;
Today:
- Messaging for point release for
apt
security vulnerability (impacts new SD installs); - Support follow-up from yesterday as needed;
- Issues work in infra & SecureDrop Workstation client land.
Blockers:
- None
Yesterday:
- Got my Qubes laptop up and running
Today:
- Attempted to do additional work on replies
Blockers:
-
There is disagreement on the format of the Authorization header between the SDK and the SecureDrop server. This impacts the client, sdk, and server itself. Resolution requires an agreement on the canonical format of the auth header and then updates the server, SDK, or both.
- Related issues: - https://github.com/freedomofpress/securedrop-client/issues/232 - https://github.com/freedomofpress/securedrop/issues/4064 - https://github.com/freedomofpress/securedrop-sdk/issues/55
-
The SDK does not parse and return the
filename
field when POSTing a reply. See https://github.com/freedomofpress/securedrop-sdk/pull/54The change proposed is technically a breaking change in that the SDK now requires that field to be present. Semver allows this change to
break and since we have an explicit warning about not using the SDK in produciton, it might be simpler to just let this
be a breaking change and merge it in without backwards compatibility.
- Once this is merged, ther needs to be a release of a new version so that development of the client can continue.
-
Yesterday:
- Reviewed/tested mickael apt fix PR
- Last night pushed up a branch fixing the 2FA test failures, will pull a PR at some point to get that merged in later today when in between release tasks
Today:
- Point Release
- Next xenial issue for me is PINENTRY gpg issue
- Figure out what is happening with SDK
Blockers:
- None
Yesterday:
- Tried 4.14.* grsec kernel with 7th series NUCs
Today:
- Support follow-up
- Started looking into logging issue for package versions
- Standing by for pre-flight checks / QA
Blockers:
- None
Yesterday:
-
Reviewed https://github.com/freedomofpress/securedrop/pull/4061
-
Added comments on upgrading monitor server (the app server is already commented), all userinput and also the screenshots for the same.
-
Updated the PR #4041 install setuptools for i18n fails Today:
-
Work on the issue for functional tests on xenial
Blockers:
- None
Yesterday:
- Fix for apt vuln
- Worked with Conor on packaging logic
Today:
- Addressed @heartsucker's comments, fixes pending re-approval
- Packaging for xenial
- Point release tasks
Blockers: None
- apt fixes on the server side
Yesterday
- 1/2 day on grant-y things
- 1/2 day on VisDe for Workstation
- Sporadic GitHub things
Today:
- Call with Qubes team to discuss their roadmap & UX scoping
- 1/2 day on grant-y things
- 1/2 day on VisDe Workstation things
Blockers:
- Not really a "blocker" but grant update deadline for the 31st fell into my lap earlier in the week and has delayed some of the VisDe stuff for the workstation—but prep for Allie has my interest in keeping that on track.