Re: [tor-bugs] #7842 [Tor bundles/installation]: make a graphical TBB installer (extractor)

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

#7842: make a graphical TBB installer (extractor)
--------------------------------------+-------------------------------------
 Reporter:  proper                    |          Owner:  mo      
     Type:  enhancement               |         Status:  assigned
 Priority:  normal                    |      Milestone:          
Component:  Tor bundles/installation  |        Version:          
 Keywords:  tbb-usability             |         Parent:          
   Points:                            |   Actualpoints:          
--------------------------------------+-------------------------------------

Comment(by mo):

 If this "one-click wrapper" is really the way we want to go, some more
 things to consider: We can't really put the files anywhere and just leave
 them lying around, as this is against the "zero footprint". Besides, it is
 a very bad custom to just leave files lying around somewhere. So, unless
 we make it clear to the user where we actually put the files (by giving
 her shortcuts or guide through the extraction process), the only way that
 is left towards a "one-click wrapper" would be to extract all files every
 time (maybe to a ramdisk), and zip them back up afterwards (to keep state
 files and customizations).
 Since we also want people to be able to upgrade and keep their changes,
 and we can't store where we actually put the last installation ("zero
 footprint"), we would have to ask the user if she wanted to import an old
 TBB profile at least on first start of the wrapper, and make her point us
 at the previous wrapper (and hope she did not just replace it already,
 thinking we keep settings stored somewhere else like a regular
 application). In general, for a working update process, we would need the
 ability to also remove files in the wrapper, because, currently, all we do
 is put more stuff into the TBB directory. Which is bad when we plan to
 drop stuff, like Vidalia or an extension.

 Replying to [comment:8 mikeperry]:
 > I don't think we need to warn about overwriting an existing Tor Browser.
 That should work in the future. It simply didn't work this time because of
 the major changes from FF10->FF17. We may end up with similar issues
 during the switch from FF17-FF24, but normally it should be fine to
 upgrade in this way, and this is how we intend to make the updater work.

 It will happen again. The wrapper/installer should at least be prepared
 for situations like that, because likely the build engineer will not have
 enough time to do it then. I don't see how overwriting currently "works",
 given it does overwrite at least custom torrc's.

 A reasonable wrapper/installer that does not need to be changed too often
 knows about configuration files (torrc and the Firefox profile, anything
 else?), copies them to a temporary location (ideally a ramdisk), deletes
 the previous installation, extracts, and copies back the config files.
 This will not work if we change torrc settings again.

 If the build engineer does not have enough time to figure out details, and
 wants to indicate that upgrading is harder than the regular upgrade
 process (currently: overwriting), it should be a simple switch to warn or
 even block extraction to an existing directory.

-- 
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/7842#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