Rewrite of aur package tor-browser-en

Question

Hi,
some months ago I packaged tor-browser-en [1] and, until now, just bumped the package version. Today I tried to rewrite it's PKGBUILD and wrapper script to increase security. I want tor-browser to be installed in ~/ instead of /opt (where it's installed currently). I do not want tor-browser to store it's data and temporary files somewhere else than my encrypted home directory.
To clarify: tor-browser's files need to be owned by the user running it, otherwise it won't work. Adjusting permissions for group-writing did not work.
I borrowed the wrapper script from the jdownloader package and customized it to fit tor-browser's needs. There are still some issues and I'm still trying to get automatic signature checking to work (especially automatic key fetching).
Did I miss anything? Is there anything absolutely wrong? Please, if possible, test and tell me what you found:
http://khg-08.de/max/tor-browser-en-2.2 … src.tar.gz
Just the wrapper script on pastebin: http://pastebin.com/HMEBJua1
[1] https://aur.archlinux.org/packages.php?ID=53169 (old version)
Last edited by Maxr (2012-03-10 21:23:28)

Answer 1

Maxr wrote:That's what the wrapper script does. It will download the source archive and copy its contents to ~/... upon first call. The aur package contains the wrapper script, desktop entry & icon, etc. Until now, tor-brower is installed to /opt/tor-browser and has to be chmodded to USER:USER by a non-root user afterwards. It's only usable for this single user. I don't like both ways ... not really sure what's better, yet.
As long as nothing gets copied into a user's home directory before that user has run a script, that's fine.
Maxr wrote:Correct me if I'm wrong, but isn't there any other way than fetching the public key from a public keyserver to check the signature? Surely, comparing fingerprints would be good, but I think most users won't do this. Automatic checking would at least ensure technical integrity of the archive, just to replace md5/shaX which would be more complex to maintain. But I'll think about it, maybe that should be solved differently.
Usually public keys are made available in several places so that the user can compare different sources to establish (probable) authenticity. My only point is that it should be left up to the user to accept the key. In a worst-case scenario, maybe the user can't trust his own connection and will have to rely on confirmation through other sources, such as calling a friend to have him check on a completely independent connection. Sure, this is unlikely to come up in most cases, but if the whole point of this is rigorous security, you may as well be rigorous.
This is mostly a devil's advocate argument. A user who really needs that level of security will either know enough to check it independently, or will eventually get caught through some other mistake anyway.