[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [tor-bugs] #2340 [Tor bundles/installation]: GPG signatures do not authenticate filenames
#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
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs