Autor: anonym Data: A: The Tails public development discussion list Assumpte: Re: [Tails-dev] Migrating to (something closer to) the regular Tor
Browser
11/10/14 13:04, intrigeri wrote: > Hi,
>
> also, the current overall state of how we install and configure the
> browser at install time is currently spread over these hooks (at
> least):
>
> * 10-tbb
> * 12-remove_unwanted_browser_searchplugins
> * 13-override-tbb-branding
> * 14-add_localized_browser_searchplugins
> * 14-generate-tor-browser-profile
> * 15-symlink-places.sqlite
>
> I see numerous small problems with that, e.g.
> 14-generate-tor-browser-profile's name is misleading, once you
> consider we now have a create_default_profile() function in 10-tbb.
True. The name should be `14-generate-tor-browser-profile-for-live-user`
or similar.
There's a comment inside it which is incorrect:
> # Generate Tor Browser profile at build time so it won't reside in RAM
When it's copied from /etc/skel into /home/amnesia, it will live in RAM.
What were we thinking here, really? To me it seems the only real use of
this is so that we can do the persistent bookmarks symlink in
`15-symlink-places.sqlite`.
> Also, the generate-tor-browser-profile script is only useful at ISO
> build time, so it probably shouldn't live in /usr/local/bin/.
> I'm pretty sure I would easily find more similar issues if I had
> a look at the other hooks.
Well, it's used in
`config/chroot_local-includes/usr/local/bin/tor-browser` too so that the
behaviour is at least more similar to how it was when we had Iceweasel.
Otherwise, removing ~/.tor-browser means that you cannot just run
`tor-browser` to get a fresh profile without the bookmarks symlink from
`15-symlink-places.sqlite`. You need to copy the profile from
/etc/tor-browser/profile manually.
Feature or regression, I don't know...
Perhaps 15-symlink-places.sqlite hook should be removed, and some
adapted persistent bookmarks symlink-creation code put into
`generate-tor-browser-profile` instead? Then there's no need for for
/etc/skel/.tor-browser, which may save a few KB from the iso size. The
bigger benefit is that things gets less confusing and more consistent.
> It would be good to take a step back and see if our current way of
> organizing things related to this topic is clear and robust enough.
> Maybe as a goal for 2.0, on the grounds that taking care of the
> general state of our codebase is definitely something we need to do to
> keep it maintainable on the long term?
