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

[Tor Bug Tracker & Wiki]

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

Comment(by rransom):

 Replying to [comment:13 dkg]:
 > Replying to [comment:11 rransom]:
 > > You wouldn't be able to label an old package like TBB-Windows 1.3.13
 as a shiny new 1.3.18, and thereby persuade users of an up-to-date version
 to 'upgrade' to a buggy older version, with the new format.
 >
 > isn't that a job of the installer itself?  I'd imagine that the tor
 installer packages will say "sorry, you already have a more recent
 version" and decline to upgrade.

 The Tor Browser Bundle is not installed, it is unpacked, and often onto a
 removable storage device in order to reduce the traces left on the
 computer(s) on which it is used.

 > > The Vidalia Bundle for Windows installer has the version numbers of
 Tor and Vidalia in its 'File Description' field.  The Tor Browser Bundle
 for Windows self-extracting archive does not have any useful version
 information on the archive itself, although a README file inside the
 archive can give a lower bound on the version.
 >
 > can you add that info to the self-extracting archive?

 That information can be added. It is too difficult to be worthwhile.

 > > The major advantage of this signing method is that Windows will verify
 the signature for users under some circumstances.  The major drawback is
 that it requires paying off the 'SSL mafia' for a code-signing
 certificate.
 >
 > i prefer to call them the "CA Cartel", but i get your point :)  What
 happens when a user tries to install a program that is signed by a code-
 signing cert that was *not* issued by a member of the cartel?  Does it
 just say "unknown issuer"?  if so, you can achieve the same approach you
 have now by distributing your own code-signing certficate separately, and
 encouraging users who want to verify the package to load that certificate
 into their system's certificate store. (i don't know how to do this
 exactly, but something like [http://msdn.microsoft.com/en-
 us/library/e78byta0.aspx certmgr.exe] is probably heading in the right
 direction)
 >
 > I'm only advocating x.509 from a tactical perspective, you understand.
 i agree that the system is flawed, and i prefer OpenPGP's multi-issuer
 certification model.  But asking people to install an entirely new (to
 them) certificate checking tool on a system just to check some other tool
 seems like you've given them two problems instead of one, so they're
 probably not going to check it anyway.

 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.

-- 
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/2340#comment:14>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online