Standup Notes 2018 11 29
Participants (alphabetical): Conor, Emmanuel, Erik, Jaysinh, Jen, Kevin, Kushal, Mike, Mickael, Nina
- Release: Two new strings in the journalist interface -- require translations. Greek and Romanian almost ready. Kushal will file issue.
Yesterday: Reviewed & merged Ansible upgrade PR.
Today: Reviewed and merge 4.4.162 kernel config PR (submitted a month ago, just cleaning up). Today targeting CI docs so we can get in the GCE logic. Xenial upgrade tasks likely not till tomorrow. PSA, I'll be logging out a bit early today.
Blockers: None
Yesterday:
- Hiring
- Sprint planning & follow-up
- UX research planning
- Light spec/issues work
- Qubes debugging & client testing
Today:
- Hiring
- Spec/issues work
- Prototype QA
Blockers:
None
Yesterday:
- Tried browsing the Kernel patching in Ubuntu.
- Observed the grsecurity kernel configurations.
Today:
- Attended UX meeting
- Browse https://github.com/freedomofpress/ansible-role-grsecurity-build try to go according to comments of emkll
Blockers:
- ansible-role-grsecurity requires grsecurity subscription (paid). -> Should not be required for wireless removal task
Yesterday:
- Hiring stuff
- Minor 0.11 release related tasks, e.g. finished testing mickael's ansible PR
- Review/merged QA loader
- Towards EOD started review gpg wrapper, will finish today
Today:
- Finish review of Gpg wrapper in client
- Wee bit more hiring stuff in PM
- Standing by to do 0.11 release bugfixes as needed
Blockers:
None
Yesterday: Bit of support work. 16.04 install on NUC hardware.
Today: Made edits to QA test plan; recorded thoughts on how Xenial upgrade could work. More time prepping for QA. Back to NUC.
Blockers: None
Yesterday:
- reviewed and merged "remove ini config file (#31)"
- reviewed and merged "remove ini config file #188 on securedrop-client"
- Updated forum for 2 new strings
- Informed translators/team about the same.
Today:
- will update the test plan from Kevin's input
Blockers: None
Yesterday: Nothing!
Today: winding down ASRE Ops on-boarding
Blockers: Qubes fires
Yesterday:
Built RC debs for 0.11.0. As part of QA -- maintainers, please apply patch that I posted to internal tracker. Found server misconfig.
Today:
QA on 0.11.0
Blockers:
None
Yesterday:
Prototyping
Today:
UX meeting this morning
Am working on prototype to get it ready for QA.
Blockers:
None
No updates
Jen: We have complicated workflow for incorporating Python wheels we build into debs. See diagram: https://github.com/freedomofpress/securedrop-debian-packaging#securedrop-debian-packaging
We should do one of two things: 1) think about ways to reduce complexity, 2) spend more time documenting process. Thoughts?
Kushal: Wrote a blog post explaining the whole process: https://kushaldas.in/posts/building-wheels-and-debian-packages-for-securedrop-on-qubes-os.html
We should think more about source tarballs we're using.
Jen: How could we do a better job verifying sources? Inspect the diffs?
Kushal: Don't have solid answer -- teams I'm working with manually inspect changes
Mickael: Let's carefully examine which dependencies are absolutely necessary. Looking at diffs for some libs is feasible, for others it may be more complicated. Would it make sense to have the wheels built at the time the packages are built? Having the wheels prebuilt does not offer an increment in assurances or security, as far as I can tell.
Kushal: We would lose deb reproducibility because wheels would be different.
Conor: As I understand it we don't have that as it is.
Mickael: wheel process itself is not reproducible. We are investing trust in person building the packages.
Kushal: That's why I asked around what other folks are doing. Almost all of them maintain their own repository like we do. Have a whitelist of packages.
Mickael: We may be conflating building and retrieval for wheels vs. build process for packages.
Kushal: Having dedicated machine in known state for building wheels and debian packages. Idea was to do this in future, as I understand.
Jen: Sounds like we agree we should have dedicated machine for the build process. What do we gain from building/pushing wheels separately?
Conor: dh-virtualenv project is most relevant for workstation. We have separate build process for SecureDrop servers, using Python/django code elsewhere. As we expand, perhaps in certain contexts, we ship application code in containers. In order to get app code to land where we need it in a way that's reliable and auditable, perhaps we can find ways to simplify.
What we've done in the past is to have dedicated hardware, disconnected unless needed.
Jen: Let's not forget we have potential uses for dh-virtualenv on server as well.
Near-term action: Architecture conversation about automated build processes.