Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Package Tails workstation code #3502

Open
redshiftzero opened this issue Jun 6, 2018 · 5 comments
Open

Package Tails workstation code #3502

redshiftzero opened this issue Jun 6, 2018 · 5 comments

Comments

@redshiftzero
Copy link
Contributor

redshiftzero commented Jun 6, 2018

Description

Right now we are still using the git checkout flow for getting new code for e.g. the Ansible playbooks and the securedrop-admin CLI onto the journalist and admin workstations. Our choices were:

  1. Asking admins to manually do the git checkout and tag verification (tons of opportunity for manual error, e.g. forgetting entirely to verify the sig),
  2. Do it in code to reduce the opportunity for mistakes like the above.

Right now we do it in code, which means we are maintaining some tricky logic (for example, we do string manipulation to verify the correct fingerprint signed the latest production tag) for verifying the tag sig in securedrop-admin update.

We should package up this code in a debian package and host on our apt repository, which we can configure in Tails.

User Stories

As a SecureDrop maintainer, I want to package and ship my code using established methods, not via git checkout.

@redshiftzero
Copy link
Contributor Author

I'm bumping this in priority, because we're jumping through some rather silly hoops (see: #3567), and because freedomofpress/securedrop-workstation#88 should go in that same package

@ghost
Copy link

ghost commented Jun 27, 2018

Since it is about creating a new package, I would suggest using the Debian GNU/Linux best practices to do so instead of the ansible based packaging logic already in place.

  • pros: better long term maintainability, showcase for refactoring other packages
  • cons: the learning curve is steep

My 2cts

P.S. Although I don't feel strongly about this, I'm willing to squabble a bit with @msheiny if he so desires

@eloquence
Copy link
Member

For the 6/27-7/11 sprint, we committed to a timeboxed deeper investigation of the possible strategies for shipping workstation code (.deb vs other non-GitHub distribution methods); a report can be added to this issue.

@redshiftzero
Copy link
Contributor Author

If we did get this package brought into Tails, then the Tails updater would obviate the need for the separate SecureDrop updater. Getting our packages in Tails would be some significant additional work, but I'm just noting this for the future. At least one user has found the two updates on the same day (since SecureDrop and Tails are released concurrently) confusing.

@KwadroNaut
Copy link
Contributor

Scoping what you (don't) want inside said package is not trivial. When using FPF's own repositories, inclusion is a lot easier. @dachary why is maintainability inside a package better?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants