Continuing the discussion from The Fedora release cycle is too short:
How is the SecureDrop Workstation doing? Does it need frequent template upgrades?
To answer my own question:
The Github is still being updated (seemingly non-trivial update three weeks ago), but there are no packages or releases.
The Freedom of the Press Foundation included it in their 2022 Impact Report, so it’s likely still got some attention.
However, since its inception in 2019 (if I remember correctly), the project seems to be advancing at a glacial pace–the documentation has its version at 0.0.1. That might just be a number though, as the documentation looks quite healthy and there’s a ‘stable’ version available for download there.
P.S. The installation procedure is intimidating to say the least, and I’ve had to tweak quite a few things back in the day to get R4.0 running on a leading-edge laptop.
All this is based on a cursory search–please correct if wrong
Hey, FPF SecureDrop dev here. The user-facing docs don’t really get versioned - there are stable and latest branches.
In terms of progress, SecureDrop Workstation entered a pilot phase with a small set of news orgs in 2020, just before the pandemic kicked off:
Since then, work’s continued at a more-or-less steady pace, with some slowdowns related to team changes and general upheaval. The most recent code audit was released in Jan 2021 - you can find it and previous ones here: Research
The pilot group has expanded a bit, and planned next steps are to close that phase out and move to general availability. You’re right to flag the install procedure - it and general maintenance are two areas in particular that need improvement for that transition to happen. Overall though, it has been getting almost universally positive feedback from folks using it. In particular, it speeds up the process of checking submissions by a good order of magnitude compared to OG SecureDrop, while preserving the security properties of the original system.
The project itself is spread across multiple repos with independent versioning schemes. Packages are pushed to FPF’s apt and yum repos, so there aren’t releases on github per se (though there probably should be, as much for documentation purposes as anything).
One thing worth noting: the Qubes team have been extremely helpful and responsive throughout the life of the project thus far!
It’s good to know that the project is chugging along nicely.
In the past I’ve wondered about Qubes’ lack of prominent, high-stakes usage in the real world, as the system (any security-oriented system) isn’t really tested until it’s out there shielding valuable targets from skilled and determined adversaries, and this lack of frontline achievement is likely what’s keeping companies from adopting Qubes.
SecureDrop can be the inflection point for the project (I’m assuming it isn’t so different that lessons learned from SecureDrop are inapplicable to Qubes proper).
Looking forward to seeing it in action!
In last year’s summit, there was a talk by someone from Nitrokey. They do support to civil society and from their talk I gathered they advised some pretty high-stakes individuals. So I’m sure many at-risk individuals already use Qubes. It’s just that for the nature of their work / life they can’t really / don’t want to be that public about it.
But yes, the SecureDrop workation is definitely the big test for the Qubes ecosystem
Imho SecureDrop workstation can be interesting for ‘normal’ Qubes users as well, since it comes with a grsecurity kernel and it is still not possible for a single home user to buy a grsecurity license afaik.
There are some differences between SecureDrop Workstation and classic Qubes use, but IMO closing the gap would make Qubes more broadly applicable.
Specifically for me the biggest diff is that SDW is a multi-VM application, which gets provisioned for minimal access (qrexec, networking, etc) automatically (compared to how, say, I and most folks use Qubes as a daily driver, which is mostly one application per vm). That way it has the security properties we’re looking for, and users don’t have to be that Linux or Qubes-savvy to avoid shooting themselves in the foot. Unfortunately it’s also non-trivial to provision something like that, hence at least part of the install friction. If that part was easier, SDW would be easier to develop against, and ideally folks would develop other similar multi-VM applications (for which Qubes is really the best and only non-spooky option).
Going back to the frequent template update question - it does need them, and those get automated and applied via a custom updater. Removing this maintenance burden and having an option to just always be on, say, Fedora latest, would be a big win for both SDW and IMO Qubes in general - so that’s another potential transferable lesson.
To be clear: I meant that there are few prominent, high-profile deployments. My point is that it’s much easier to convince people and companies to choose Qubes when it’s visibly out there on the battlefield shielding prime targets, so to speak.
And just to pre-empt some people: endorsements are not the same thing as deployments.