Bug #12719

tails should not include binary blobs by default

Added by dachary 2017-06-15 10:32:54 . Updated 2017-06-23 11:51:20 .

Status:
Rejected
Priority:
Normal
Assignee:
Category:
Target version:
Start date:
2017-06-15
Due date:
% Done:

0%

Feature Branch:
Type of work:
Security Audit
Blueprint:

Starter:
Affected tool:
Deliverable for:

Description

It looks like proprietary binary firmware blobs are included by default:

https://labs.riseup.net/code/projects/tails/repository/revisions/stable/entry/config/chroot_apt/preferences#L17

Explanation: src:firmware-nonfree
Package: firmware-linux firmware-linux-nonfree firmware-amd-graphics firmware-atheros firmware-brcm80211 firmware-intel-sound firmware-ipw2x00 firmware-iwlwifi firmware-libertas firmwa\
re-misc-nonfree firmware-realtek firmware-ti-connectivity
Pin: release o=Debian,n=sid
Pin-Priority: 999

Subtasks

History

#1 Updated by intrigeri 2017-06-15 10:42:09

  • Status changed from New to Rejected

This is on purpose, and documented there:

#2 Updated by dachary 2017-06-15 10:49:51

Thanks for the links. It should be prominently advertised, don’t you think ? I mean that these binary blobs are a security hazard. How much privacy can I really expect when the firmware of the network chip of my computer is running within tails ? Maybe it’s already been covered and I’d be grateful if you could direct me to the relevant page.

#3 Updated by dachary 2017-06-18 13:59:31

Instructions to remove the blobs and rebuild an ISO at http://dachary.org/?p=4116

#4 Updated by intrigeri 2017-06-23 11:51:20

> Thanks for the links. It should be prominently advertised, don’t you think ?

Perhaps. Let’s discuss this on Bug #12722.

> I mean that these binary blobs are a security hazard. How much privacy can I really expect when the firmware of the network chip of my computer is running within tails ?

Meta: if you really want to reopen this discussion, please do so on the tails-dev@boum.org mailing list, as it’s a project-wide political/strategy debate, and very few of us follow all Redmine activity. Don’t set your expectations too high though: this point has been raised many, many times since the early days of this project, and we’re pretty much convinced that the trade-off we currently do is the best we can do for our users (we don’t target only the intersection of “FOSS geeks who care about this and choose the hardware they buy carefully to avoid the need to load firmware at runtime” and “privacy-aware people who know they want to use Tails”; that would be a pretty tiny userbase, and it’s not the strategy we’ve chosen, even though I respect, understand and appreciate that other projects have different priorities and a different strategy; e.g. as a Debian developer myself, I’m glad that Debian does not include proprietary firmware by default, but that’s a very different situation since users can individually choose to install the firmware they need once for all there). So unless new arguments/facts are brought on the table, starting the same discussion yet another time is unlikely to be very useful and pleasurable for anyone.

I don’t want to have this debate here, but I’ll add two comments anyway and then I’ll shut up:

  • Such firmware does not run on the main CPU “within Tails”. It runs on the network device it’s about.
  • Your argument works both ways: one could ask how much privacy/safety I can really expect if the very same proprietary firmware code is hard-coded in a read-only manner in the network device, without any chance to fix bugs and security issues in it later on.

> Maybe it’s already been covered and I’d be grateful if you could direct me to the relevant page.

See Bug #12719#note-1, that’s all we have so far.