Securedrop: Add "securedrop-admin upgrade" command

Created on 5 Feb 2018  ·  2Comments  ·  Source: freedomofpress/securedrop

Description

Every release, we ask admins to do the same commands to update securedrop-admin in their admin workstation:

cd ~/Persistent/securedrop
git fetch --tags
git checkout <latest_release_tag>
gpg --recv-key "2224 5C81 E3BA EB41 38B3 6061 310F 5612 00F4 AD77”
git tag -v <latest_release_tag>  # Output should include “Good Signature”

Since there are several manual steps and they involve using git, they are confusing to admins. We could provide a securedrop-admin upgrade command that did these steps for them and would only bail out 1. there is no new release or 2. if the signature does not verify.

User Stories

As a SecureDrop administrator, I want an easier way to upgrade my securedrop-admin so that I don't make a mistake.

Python feature opdeployment

Most helpful comment

Commit 1f7e8d1 contains an implementation of this feature - check it out and let me know what you think @kushaldas 😄

To explain fully the broader context around this ticket and that branch, from what I've observed with our users there are four problems around updating SecureDrop in Tails:

  1. Admins and journalists have to do this git song and dance (what this issue is about), which ends up being doable _but_ frustrating for admins and not doable at all for 95% of journalists. It's also error prone for all users, as they can easily accidentally skip verifying the signature on the update: this is not ideal.
  2. When we issue an update that requires the execution of securedrop-admin tailsconfig (example: #2620), again admins _can_ do it but journalists cannot, meaning that likely the update just doesn't happen :cry:
  3. Admins and journalist aren't alerted in Tails that a SecureDrop update is available, so unless they are super attentive to the SecureDrop support portal / blog / Twitter they aren't doing updates promptly. In an ideal world we'd want what Tails has implemented - a check occurring behind the scenes (securedrop-admin check_for_updates in 1f7e8d1) and a dialog box that appears saying "SecureDrop updates are available" so that users that are conditioned to do updates can do them. This should do the update to the latest git tag, verify the sig, and then run securedrop-admin tailsconfig.
  4. Journalists should not ever be expected to use the command line. Admins are often physically separated from journalists, and requiring their intervention to do this command line stuff is a big burden. So we need a GUI at minimum to do the tasks that journalists need to do.

Anyway so my idea was to just have a wee Qt program that does the update, sig verification and tailsconfig pieces for journalists. The updating and sig verification part built on 1f7e8d1 is in branch qt-journalist-updater and looks like this:

updater-v1

The tailsconfig part is commented out right now because the sudo password is needed for tailsconfig so we'll need to have a little prompt appear for that.

One possibility to also address problem 3 above is to have securedrop-admin check_for_updates run on boot as part of our network hook - this could be done in a separate thread or the Desktop will take a while to appear, which is annoying. Haven't tested that yet, but an idea.

Thoughts welcome

All 2 comments

Commit 1f7e8d1 contains an implementation of this feature - check it out and let me know what you think @kushaldas 😄

To explain fully the broader context around this ticket and that branch, from what I've observed with our users there are four problems around updating SecureDrop in Tails:

  1. Admins and journalists have to do this git song and dance (what this issue is about), which ends up being doable _but_ frustrating for admins and not doable at all for 95% of journalists. It's also error prone for all users, as they can easily accidentally skip verifying the signature on the update: this is not ideal.
  2. When we issue an update that requires the execution of securedrop-admin tailsconfig (example: #2620), again admins _can_ do it but journalists cannot, meaning that likely the update just doesn't happen :cry:
  3. Admins and journalist aren't alerted in Tails that a SecureDrop update is available, so unless they are super attentive to the SecureDrop support portal / blog / Twitter they aren't doing updates promptly. In an ideal world we'd want what Tails has implemented - a check occurring behind the scenes (securedrop-admin check_for_updates in 1f7e8d1) and a dialog box that appears saying "SecureDrop updates are available" so that users that are conditioned to do updates can do them. This should do the update to the latest git tag, verify the sig, and then run securedrop-admin tailsconfig.
  4. Journalists should not ever be expected to use the command line. Admins are often physically separated from journalists, and requiring their intervention to do this command line stuff is a big burden. So we need a GUI at minimum to do the tasks that journalists need to do.

Anyway so my idea was to just have a wee Qt program that does the update, sig verification and tailsconfig pieces for journalists. The updating and sig verification part built on 1f7e8d1 is in branch qt-journalist-updater and looks like this:

updater-v1

The tailsconfig part is commented out right now because the sudo password is needed for tailsconfig so we'll need to have a little prompt appear for that.

One possibility to also address problem 3 above is to have securedrop-admin check_for_updates run on boot as part of our network hook - this could be done in a separate thread or the Desktop will take a while to appear, which is annoying. Haven't tested that yet, but an idea.

Thoughts welcome

The command line part is the same logic I had :)

One possibility to also address problem 3 above is to have securedrop-admin check_for_updates run on boot as part of our network hook - this could be done in a separate thread or the Desktop will take a while to appear, which is annoying. Haven't tested that yet, but an idea.

securedrop-admin check_for_updates with a notification entry/PyQt application should run a separate process as the part of the network hook. I always used to choose PyQt as my standard GUI toolkit, so I am totally in for this.

Was this page helpful?
0 / 5 - 0 ratings