Re: [tor-bugs] #2340 [Tor bundles/installation]: GPG signatures do not authenticate filenames

["Tor Bug Tracker & Wiki" <blackhole@xxxxxxxxxxxxxx>]

#2340: GPG signatures do not authenticate filenames
--------------------------------------+-------------------------------------
 Reporter:  rransom                   |          Owner:  rransom 
     Type:  defect                    |         Status:  assigned
 Priority:  critical                  |      Milestone:          
Component:  Tor bundles/installation  |        Version:          
 Keywords:                            |         Parent:          
   Points:                            |   Actualpoints:          
--------------------------------------+-------------------------------------

Comment(by proper):

 I've been thinking about this a lot. First of all, for all who like to
 think about this as well, some information (if you don't already know):

  * [http://www.updateframework.com/projects/project TUF: The Update
 Framework] (Thandy successor, under active development)
  * [http://www.updateframework.com/projects/project/wiki/Docs/Security
 TUF's excellent threat model and brief summary of various attacks on
 software updaters]

 Replying to [comment:14 rransom]:
 > Once we have an easy-to-use package verification tool, we should release
 binaries of it signed using each OS's code-signing system. That is not a
 substitute for implementing TUF and releasing a package verifier based on
 TUF.

 Even if you had this, it would have horrible usability (doing-it-right (r)
 and wouldn't be of help for many users. Users still would have to blindly
 trust the easy-to-use package verification tool on first download or use
 ordinary complicated verification to get it in the first place.

 The problem anyone who wants to ship software, such as The Tor Project, is
 that operating systems doesn't have an easy and secure way to obtain
 software from third parties. (None including end to end verification,
 defense against rollback attacks, deterministic builds, quorum signatures,
 etc.) Ideas...

 Windows:

  * [http://www.windows8appstore.com/ Windows Appstore] maybe? Well,
 Microsoft knew who downloaded Tor Browser, but anonymously obtaining Tor
 Browser is difficult anyway and Microsoft has a say what goes into they
 store and what not. Tor Browser may not be able to get in for some obscure
 reason. That's something open for research/communication. You won't find
 great solutions for the Microsoft operating system, since they're not
 interested to support your case.

 Debian:

  * Since #3994 "Get TorBrowser in Debian" is unrealistic, maybe at least
 #5236 "Make a deb of the Torbrowser and add to repository" is realistic?
  * But even if you had #5236, how to get people the repository signing key
 and apt line? Debian lacks something like "sudo apt-get install
 torproject-repository" or "sudo apt-get install torproject/tbb" to install
 tbb from a third party (torproject).
  * And even if you had this, you still wouldn't have quorum signatures.
  * There are no graphical package mangers for Debian with good usability.
 (Well, there is Software Center, but it has [http://bugs.debian.org/cgi-
 bin/pkgreport.cgi?pkg=software-center;dist=unstable bugs] which make it
 unusable.)

 Conclusion:

 All in all, getting a highly secure and usable software update tool where
 third parties can easily and reliably ship their stuff isn't trivial. In
 short term, I suggest creating a draft. What today's built-in software
 update tools (apt-get etc.) can do, which features are lacking, sketching
 the software update tool of your third party dreams. And then hope someone
 creates or get it founded.

-- 
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/2340#comment:18>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs