Hi, I'm trying to put up an ebuild for the Tor Browser Bundle for Gentoo. As you may know an ebuild is a script which automates the build of a certain application. We already have something in Portage [2] (the official ebuild repository) but it's in an experimental state and we want to make sure that it's something useful and not harmful. So I'd like to know your opinion about the idea as whole (is it a good idea at all to build by yourself the TBB instead of using the official one?) and what could be the main problems arising in such an operation. So: 1. Can you name a list of tools to fingerprint a browser so we can compare our ebuild with the official TBB? 2. Which version should we use? We were planning to offer both the current official release (even if TBB for Linux is currently in beta) and something more recent, even if AFAIK this would be for testing purpose only and could weaken anonymity and untrackability. 3. We plan to use the system version of the Tor client, in my understanding it should not be a problem to use a Tor client with a version different from the one officially released, but I could be wrong. We also plan to exclude vidalia (and the "0015-Make-Tor-Browser-exit-when-not-launched-from-Vidalia.patch" patch). 4. We have a different ebuild for the Firefox profile directory (so if it's not installed the HTTPS Everywhere plugin won't be installed), is this a good idea or would it be better to integrate them? 5. Gentoo build system offers USE flags, which are options that allow to customize the way the package is built. These are the USE flag available for the standard Firefox ebuild in Gentoo, which is the base for our build of the TBB: 1. alsa: Adds support for media-libs/alsa-lib (Advanced Linux Sound Architecture) 2. bindist: Disable official Firefox branding (icons, name) which are not binary-redistributable according to upstream. 3. custom-cflags: Build with user-specified CFLAGS (unsupported) 4. custom-optimization: Fine-tune custom compiler optimizations, setting this is not recommended. 5. dbus: Enable dbus support for anything that needs it (gpsd, gnomemeeting, etc) 6. debug: Enable extra debug codepaths, like asserts and extra output. If you want to get meaningful backtraces see http://www.gentoo.org/proj/en/qa/backtraces.xml 7. ipc: Use inter-process communication between tabs and plugins. Allows for greater stability in case of plugin crashes 8. libnotify: Enable desktop notification support 9. minimal: Prevent sdk and headers from being installed 10. pgo: Add support for profile-guided optimization using gcc-4.5, for faster binaries. This option will double the compile time. 11. startup-notification: Enable application startup event feedback mechanism 12. system-sqlite: Use the system-wide dev-db/sqlite installation with secure-delete enabled 13. webm: Use system media-libs/libvpx for HTML5 WebM video support. 14. wifi: Enable wireless network functions Looking at the TBB build script this the combination of USE flags to make as similar as possible to the official release (minus means the USE flag is disabled): -pgo -debug -bindist -custom-optimization -crashreporter webm ipc system-sqlite -wifi. I'm planning to remove the possibility to configure these use flags. Do you agree? For further details you can take a look at the ebuild [1], which should be understandable. Take a look also at the current ebuild for TBB [2]. Is there something else we should pay attention to in the build process or in general? Thanks in advance, Alessandro Di Federico [1] http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/www-client/firefox/f... http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/eclass/mozconfig-3.e... [2] http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/www-client/torbrowse...
On 2012-08-12, at 1:21 PM, Alessandro Di Federico wrote:
Hi, I'm trying to put up an ebuild for the Tor Browser Bundle for Gentoo. As you may know an ebuild is a script which automates the build of a certain application. We already have something in Portage [2] (the official ebuild repository) but it's in an experimental state and we want to make sure that it's something useful and not harmful.
Portage offers no authentication and no confidentiality. So unless you really trust your mirror(s) -- and every node between the two of you -- you're better off downloading TBB from the Tor Project website. Mansour
On Sun, 2012-08-12 at 15:11 -0400, Mansour Moufid wrote:
Portage offers no authentication and no confidentiality.
Each file has a SHA-256, SHA-512 and Whirlpool hash associated. This hashes are in Portage, and if you're a security-aware user (as most of Gentoo users are) you can get it in a secure way, which means PGP-signed. Take a look at the handbook: http://www.gentoo.org/doc/en/handbook/2008.0/handbook-x86.xml?part=2&chap=3#... Confidentiality is not required, because currently we distribute TBB patches with portage, so you get them along with all the other Portage updates as all the Gentoo users. The rest looks like a normal Firefox installation. The Tor client is fetched through HTTPS. Ale
On 2012-08-12, at 3:36 PM, Alessandro Di Federico wrote:
On Sun, 2012-08-12 at 15:11 -0400, Mansour Moufid wrote:
Portage offers no authentication and no confidentiality.
Each file has a SHA-256, SHA-512 and Whirlpool hash associated. This hashes are in Portage, and if you're a security-aware user (as most of Gentoo users are) you can get it in a secure way, which means PGP-signed.
Take a look at the handbook: http://www.gentoo.org/doc/en/handbook/2008.0/handbook-x86.xml?part=2&chap=3#...
Portage uses rsync to get the ebuild and Manifest (signed hashes) from mirrors, which, along with anyone in between, can send you bogus ebuilds with whatever Manifest. Even with webrsync you still have to trust the mirror(s), and then the Gentoo release infrastructure... Getting TBB from tp.o with Chrome is end-to-end and secure. Anyway, good luck. Mansour
On Sun, Aug 12, 2012 at 1:21 PM, Alessandro Di Federico <ale@clearmind.me>wrote:
Hi, I'm trying to put up an ebuild for the Tor Browser Bundle for Gentoo. As you may know an ebuild is a script which automates the build of a certain application. We already have something in Portage [2] (the official ebuild repository) but it's in an experimental state and we want to make sure that it's something useful and not harmful.
So I'd like to know your opinion about the idea as whole (is it a good idea at all to build by yourself the TBB instead of using the official one?) and what could be the main problems arising in such an operation. So:
1. Can you name a list of tools to fingerprint a browser so we can compare our ebuild with the official TBB? 2. Which version should we use? We were planning to offer both the current official release (even if TBB for Linux is currently in beta) and something more recent, even if AFAIK this would be for testing purpose only and could weaken anonymity and untrackability. 3. We plan to use the system version of the Tor client, in my understanding it should not be a problem to use a Tor client with a version different from the one officially released, but I could be wrong. We also plan to exclude vidalia (and the "0015-Make-Tor-Browser-exit-when-not-launched-from-Vidalia.patch" patch). 4. We have a different ebuild for the Firefox profile directory (so if it's not installed the HTTPS Everywhere plugin won't be installed), is this a good idea or would it be better to integrate them? 5. Gentoo build system offers USE flags, which are options that allow to customize the way the package is built. These are the USE flag available for the standard Firefox ebuild in Gentoo, which is the base for our build of the TBB: 1. alsa: Adds support for media-libs/alsa-lib (Advanced Linux Sound Architecture) 2. bindist: Disable official Firefox branding (icons, name) which are not binary-redistributable according to upstream. 3. custom-cflags: Build with user-specified CFLAGS (unsupported) 4. custom-optimization: Fine-tune custom compiler optimizations, setting this is not recommended. 5. dbus: Enable dbus support for anything that needs it (gpsd, gnomemeeting, etc) 6. debug: Enable extra debug codepaths, like asserts and extra output. If you want to get meaningful backtraces see http://www.gentoo.org/proj/en/qa/backtraces.xml 7. ipc: Use inter-process communication between tabs and plugins. Allows for greater stability in case of plugin crashes 8. libnotify: Enable desktop notification support 9. minimal: Prevent sdk and headers from being installed 10. pgo: Add support for profile-guided optimization using gcc-4.5, for faster binaries. This option will double the compile time. 11. startup-notification: Enable application startup event feedback mechanism 12. system-sqlite: Use the system-wide dev-db/sqlite installation with secure-delete enabled 13. webm: Use system media-libs/libvpx for HTML5 WebM video support. 14. wifi: Enable wireless network functions
Looking at the TBB build script this the combination of USE flags to make as similar as possible to the official release (minus means the USE flag is disabled): -pgo -debug -bindist -custom-optimization -crashreporter webm ipc system-sqlite -wifi. I'm planning to remove the possibility to configure these use flags. Do you agree? For further details you can take a look at the ebuild [1], which should be understandable. Take a look also at the current ebuild for TBB [2].
Is there something else we should pay attention to in the build process or in general?
Thanks in advance, Alessandro Di Federico
[1] http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/www-client/firefox/f...
http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/eclass/mozconfig-3.e... [2] http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/www-client/torbrowse...
_______________________________________________ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Hi Alessandro, After thinking about this for a little bit, here's my 2 cents. =) 1) The ebuild is specifically for building the Tor browser, not the bundle. The package name of the ebuild states this but the email mentions the bundle. 2) One of the best reasons for using the bundle is that it is self-contained. If you want to use the bundle for anonymity you can easily do this and then discard it will little trace. This becomes much more difficult with a system-level install. 3) On the other hand, I see no reason to restrict a security-conscious user from using a more secure browser, as long as they understand the trade-offs. However, torprofile should not be an optional USE flag. Only adding some patches from upstream does not make it the Torbrowser. 4) Given 3), is there a reason Tor is not at least an optional RDEPEND for torbrowser via a USE flag (or another way)? 5) If you did/do intend to create an ebuild for the TBB and not just the browser, it should provide the exact same experience as if the user downloaded it from torproject.org. I think this should include Vidalia launching Torbrowser once the network is configured. 6) Make sure the ebuild references Tor and not TOR However, I think because of 1) it's difficult to provide a little better feedback. Is your goal to only provide an alternative browser or are you attempting to provide the full bundle? Thanks, - Matt
On Sun, 2012-08-12 at 18:28 -0400, Matthew Finkel wrote:
After thinking about this for a little bit, here's my 2 cents. =)
1) The ebuild is specifically for building the Tor browser, not the bundle. The package name of the ebuild states this but the email mentions the bundle.
You're right, we want to build the Tor browser, not the TBB.
2) One of the best reasons for using the bundle is that it is self-contained. If you want to use the bundle for anonymity you can easily do this and then discard it will little trace. This becomes much more difficult with a system-level install.
This is true, but in some scenarios (e.g. full disk encryption) having a system Tor Browser, could allow to have more easily sophisticated configurations. Using Tor Browser could even be a company policy in certain cases. Having a system Tor Browser would offer some advantages.
3) On the other hand, I see no reason to restrict a security-conscious user from using a more secure browser, as long as they understand the trade-offs. However, torprofile should not be an optional USE flag. Only adding some patches from upstream does not make it the Torbrowser.
Right, what we're willing to offer to the user is a web client which looks exactly the same as the Tor Browser to the web server he's connecting to, but leave all the rest easily configurable. Gentoo philosophy focuses a lot on the freedom of choice. The point now is be sure that our Tor Browser looks exactly like the official one, therefore all my questions.
4) Given 3), is there a reason Tor is not at least an optional RDEPEND for torbrowser via a USE flag (or another way)? 5) If you did/do intend to create an ebuild for the TBB and not just the browser, it should provide the exact same experience as if the user downloaded it from torproject.org. I think this should include Vidalia launching Torbrowser once the network is configured. 6) Make sure the ebuild references Tor and not TOR
I think we'll require Tor and integrate the Tor Browser profile. Thanks for your answer, Ale
participants (3)
-
Alessandro Di Federico -
Mansour Moufid -
Matthew Finkel