Feature #11127

Stop distributing detached signatures of Torrent files

Added by sajolida 2016-02-14 12:12:26 . Updated 2016-02-22 07:59:48 .

Status:
Rejected
Priority:
Normal
Assignee:
Category:
Installation
Target version:
Start date:
2016-02-14
Due date:
% Done:

0%

Feature Branch:
Type of work:
Discuss
Blueprint:

Starter:
Affected tool:
Installation Assistant
Deliverable for:

Description

Between January 1 and January 20 (before 2.0), we served downloads of:

  • 33366 .torrent files
  • 2308 .torrent.sig files
  • 23669 .iso.sig files

From a security point of view, checking both the .torrent.sig and the .torrent.iso doesn’t bring much as BitTorrent clients are pretty good as hash verification (Feature #9043).

Seeing that our .torrent.sig amount for 7% of the download of our .torrent, I wonder whether it’s worth the bits of work to generate the signature and the added complexity in documentation and possible confusion from refering to two different detached signatures to verify, all-in-all, the same end content, a Tails ISO.

Also note that so far in the installation assistant we’re not point to the .torrent.sig file at all. So if want to keep them we need to adjust the assistant accordingly. See also Bug #11019.


Subtasks


Related issues

Related to Tails - Feature #8832: Assistant: Removing signature from Torrent Rejected 2015-02-02
Related to Tails - Bug #10781: Adapt the download of release candidates to the assistant Resolved 2016-02-13
Related to Tails - Bug #11019: Clarify that BitTorrent verification doesn't replace OpenPGP verification Resolved 2016-01-28
Related to Tails - Bug #11157: Link to the detached signature of the ISO in the torrent documentation Rejected 2016-02-22
Related to Tails - Bug #11121: Adjust our release process to publish torrents for betas and RCs Resolved 2016-02-13

History

#1 Updated by sajolida 2016-02-14 12:12:47

  • related to Feature #8832: Assistant: Removing signature from Torrent added

#2 Updated by sajolida 2016-02-14 12:12:59

  • related to Bug #10781: Adapt the download of release candidates to the assistant added

#3 Updated by sajolida 2016-02-14 12:13:06

  • related to Bug #11019: Clarify that BitTorrent verification doesn't replace OpenPGP verification added

#4 Updated by sajolida 2016-02-14 12:13:20

  • Status changed from New to Confirmed

#5 Updated by intrigeri 2016-02-14 13:42:30

  • Assignee set to sajolida
  • QA Check set to Info Needed

> From a security point of view, checking both the .torrent.sig and the .torrent.iso doesn’t bring much as BitTorrent clients are pretty good as hash verification (Feature #9043).

What do you mean with “checking both the .torrent.sig and the .torrent.iso”?

Note that if we do what’s proposed here, we probably have to rediscuss Feature #8832 since some of the reasoning there was based on the fact that we did provide strong cryptographic means to verify the Torrent file itself.

#6 Updated by sajolida 2016-02-15 14:38:45

redmine@labs.riseup.net:
> What do you mean with “checking both the .torrent.sig and the .torrent.iso”?

Sorry for the typo, I meant “checking both the .torrent.sig and the
.iso.sig”.

> Note that if we do what’s proposed here, we probably have to rediscuss Feature #8832 since some of the reasoning there was based on the fact that we did provide strong cryptographic means to verify the Torrent file itself.

I kind of changed my mind, see Feature #8832#note-21. Still,
web/11019-bittorrent-openpgp is not merged yet, that’s why I didn’t
close Feature #8832 yet.

#7 Updated by cypherpunks 2016-02-21 10:13:48

I really don’t like this idea at all, because it means people will not be able to verify a file with a complex and obscure format (bencode, which is really only used in torrent files). A number of things can go wrong if the torrent file has been tampered with. Give me any popular torrent client, and in all likelyhood I will be able to fuzz it with AFL and find an exploitable bug in the bencode parser.

At the very least, make a .torrent.sig file advertised as optional. If you remove it entirely, people can get exploited before they even get to the point of verifying Tails.

#8 Updated by sajolida 2016-02-22 07:59:33

  • related to Bug #11157: Link to the detached signature of the ISO in the torrent documentation added

#9 Updated by sajolida 2016-02-22 07:59:48

  • Status changed from Confirmed to Rejected
  • Assignee deleted (sajolida)

Thanks for the additional arguments. I checked the security tracker of transmission and indeed I found two security issues (out of 8) triggered by malformed torrent file: CVE-2010-0012 and CVE-2012-4037. So that’s a valid concern.

https://security-tracker.debian.org/tracker/source-package/transmission

I created Bug #11157 to track this and can now close this one as rejected.

#10 Updated by sajolida 2016-02-25 15:35:13

  • related to Bug #11121: Adjust our release process to publish torrents for betas and RCs added