Bonjour,
tl;dr: will I be able to get a bug/security fix only release for 0.3 after 0.4 is released ?
The current SecureDrop releases have both bug fixes and new features. This is what someone will get, for instance, when upgrading from 0.3.12 to 0.4. Then there will be 0.4.1, 0.4.2 etc.
Upgrading multiple machines to a new version is significant work and it must be done carefully. Reason why most organisation prefer to do it on their own time, when the benefits of new features is enough of a motivation. Bug fixes, specially security fixes, on the other hand need to be installed as soon as possible. This distinction is the reason for maintaining stable releases that are expected to see only bug fixes.
It is unclear to me if the SecureDrop releases follow this release model. If that’s the case I would assume that 0.4.1, 0.4.2 etc. are updates to the 0.4 stable release with bug fixes only while 0.5 is being prepared in the develop branch. But git-flow does not make room for this. Since all releases are merged back to master, there will be no way to publish a bug fix only release for 0.4 after 0.5 is released. Meaning 0.4 installations will be forced to upgrade to 0.5 to get the latest bug fixes / security fixes.
There are many ways to deal with this and it is entirely possible that I missed something 
What do you think ?
Great question, @dachary. There are multiple components of SecureDrop that need to be updated, according to different version streams. The most straightforward is the SecureDrop application code, running on the SecureDrop Application Server. That code updates automatically whenever we release a new version, via the nightly cron job that polls the FPF apt repository for updates. If updates are found, they are installed. Admins can check whether they’re up to date by viewing the Source Interface and checking for the string “Powered by SecureDrop x.y.z” at the bottom.
For components that FPF does not manage, such as Tails, those updates must be performed manually by Admins. We recently announced the need to upgrade the Tails drives manually.
Related to the Tails updates, Admins must pull the latest release tag from GitHub and verify the GPG signature to keep the scripts up to date on the Admin Workstation. This is generally only necessary when a release requires manual action on the part of an Admin, which is rare, and we explicitly state the need for manual action in announcements when appropriate.
Since the application code updates automatically, we can rather safely assume instances are upgrading around the same time we’re publishing new versions. That’s of course an optimistic assumption, so we also monitor the Source Interfaces programmatically, via Nagios, so that after a release we can confirm that the updates applied well (by parsing out the displayed version string). In the event that an instance fails to upgrade, we reach out to the Admin directly for more information. This only works for organizations that have contacted us so we’re aware of the instance—technically anyone can run SecureDrop, and they don’t need to notify FPF—but it’s been working well so far.
1 Like
What do you think ?