SecureDrop vulnerability and return to regular release cycle

SecureDrop’s 0.4.4 release ended up being a hotfix release to fix a major vulnerability discovered in SecureDrop during QA. Unfortunately this means that the planned beta release of internationalization and other exciting changes did not (yet!) occur. You can read the release announcement for SecureDrop 0.4.4 and the vulnerability response which describes how Freedom of the Press Foundation are working with individual news organizations here:


This will involve some significant ongoing work for SecureDrop engineers for the next 2-3 weeks as we travel to assist organizations that elected to reinstall SecureDrop.

That said, I suggest that we continue to merge changes into develop as they are ready, and retarget the release of what’s currently in develop for December 5th (this was the next scheduled release date in https://github.com/freedomofpress/securedrop/wiki/Development-Roadmap, which I’ll update soon).

This will give us a little bit of breathing room to finish up our response to the security vulnerability and spend extra time QAing the extensive changes for 0.5. This will be SecureDrop 0.5 since by that time the journalist refactor will likely be merged (related: I want us to start using 0.x for the regular releases and 0.x.y for hotfixes such that we don’t need to rename versions for hotfixes (what we currently do), which is a bit confusing for people that don’t follow this project very closely).

A nice bonus here is that we get another attempt at string freeze, which would be November 27th with a release December 5th. Another nice bonus is that translations in any additional languages that are ready by December 5th will be merged in.

tl;dr:

0.5 String freeze: November 27th
0.5 Release: December 5th

If you disagree or think that this is not the best course of action, please respond and we can come to a consensus on the best path forward :smiley:

1 Like

How would we signal to Admins that a version might require extra attention or any manual steps? I think we could use the Rust approach to SemVer which is “leading zero means breaking change” and until we hit 1.0, we just keep bumping the patch version. Hotfixes could be a 0.x.y.z whereas normal packages would still be 0.x.y. Once we hit 1.0, we drop the 4th version.