Re: [tor-dev] TBB Gentoo ebuild
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 12 Aug 22:56 Mansour Moufid:
Even with webrsync you still have to trust the mirror(s), and then the Gentoo release infrastructure...
Forgive me my bluntness, but how is that different from trusting you? The methods are reliable, being Manifests and webrsync, the unknown variable is the trust you give the ones providing you with ebuilds. But those are identified by gpg on both levels. And the TBB is even worse, cause I also have to trust what's in the binaries. There is no way to tell what was actually compiled there. It could be something different than the sources on the git server. 13 Aug 00:28 Matthew Finkel:
4) Given 3), is there a reason Tor is not at least an optional RDEPEND for torbrowser via a USE flag (or another way)?
There are no optional runtime-only dependencies in gentoo, this could change with GLEP 62. http://www.gentoo.org/proj/en/glep/glep-0062.html I could however tell the user after compilation that he might want to use tor with this...erm... but I thought that's obvious. The fact that it's not forced for RDEPEND is simply, because there are setups where this is not wanted/required. 13 Aug 00:28 Matthew Finkel:
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.
Definitely not. The intention is not to provide an all-in-one experience. I already had those arguments with the guys from #tor All I am interested in is the question about the firefox build-time configuration and if different build-time configurations could lead to vulnerability in the tor network. If there is the slightest doubt about that, I will remove this ebuild at once or fix it. - - hasufell -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJQOpaJAAoJEFpvPKfnPDWzpI4H/igZDuVGyjdKEl9SvvV9gnY0 72esQTiHfx00gO42lOguutwBX54DV/S7HggEZy1P9UIi5gfJckrFKsM3Y9oD9tUX X9EZA6WEU3F90MD0gFFxH2jcoEbm85UfjJkEwI2Hy1+lEOPAZqzBV1F0sBE/Xd/U WwIgAHy8jKsTI1RTIW8r4VOoexifCllWvjbKiDNxeeixTQhwhvrCWnbqTI0WKR95 Er6LNwwYNh+Ugu7s6OwR7o3cUAuOXt3LUjf45bEGAgPF+lrqsXrfB9N5ANu+3177 94sxHgzYkRSsORjjl678/tZFfyp1jagX1FcT6O1dd/J4sHqfRdyZfy29d0DH/e0= =gCI5 -----END PGP SIGNATURE-----
On 2012-08-26, at 5:35 PM, julian wrote:
12 Aug 22:56 Mansour Moufid:
Even with webrsync you still have to trust the mirror(s), and then the Gentoo release infrastructure...
Forgive me my bluntness, but how is that different from trusting you?
I have nothing to do with Tor.
And the TBB is even worse, cause I also have to trust what's in the binaries. There is no way to tell what was actually compiled there. It could be something different than the sources on the git server.
OK...
On Sun, Aug 26, 2012 at 5:35 PM, julian <julian.ospald@googlemail.com> wrote:
13 Aug 00:28 Matthew Finkel:
4) Given 3), is there a reason Tor is not at least an optional RDEPEND for torbrowser via a USE flag (or another way)?
There are no optional runtime-only dependencies in gentoo, this could change with GLEP 62. http://www.gentoo.org/proj/en/glep/glep-0062.html
I could however tell the user after compilation that he might want to use tor with this...erm... but I thought that's obvious. The fact that it's not forced for RDEPEND is simply, because there are setups where this is not wanted/required.
Ah, I apologize, I thought having optional runtime deps were possible. I also agree that is should be obvious but I've learned to err on the side of caution, if possible.
13 Aug 00:28 Matthew Finkel:
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.
Definitely not. The intention is not to provide an all-in-one experience. I already had those arguments with the guys from #tor
Okay, so you want to add the TorBrowser to portage so that a user can emerge all of the components of the TBB and can use them as he/she sees fit, correct?
All I am interested in is the question about the firefox build-time configuration and if different build-time configurations could lead to vulnerability in the tor network. If there is the slightest doubt about that, I will remove this ebuild at once or fix it.
I'm not a browser dev, but I don't think this shouldn't be an issue. As long as the ebuild uses all of the security patches and extensions, it shouldn't be a problem. Also, if any vulnerabilities are introduced by this ebuild, it would only harm the user's anonymity and should not have an impact on the network.
- - hasufell
- Matt
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 08/27/2012 08:26 PM, Matthew Finkel wrote:
Ah, I apologize, I thought having optional runtime deps were possible. I also agree that is should be obvious but I've learned to err on the side of caution, if possible.
Optional runtime-ONLY dependencies pulled in by a useflag are possible, they just violate the _current_ spec ;) GLEP 62 tries to enhance the spec, so we can get an implementation where this is valid. (OT stripped)
Definitely not. The intention is not to provide an all-in-one experience. I already had those arguments with the guys from #tor
Okay, so you want to add the TorBrowser to portage so that a user can emerge all of the components of the TBB and can use them as he/she sees fit, correct?
That's right, but I could however enhance the elog which is printed out to the user after the build and installation is complete. I was also considering to hard-mask this package. It's currently only marked 'unstable', but hard-masking would mean the user has to take extra steps in order to install it which would maybe make it more clear that this is not supported or recommended by Tor upstream.
All I am interested in is the question about the firefox build-time configuration and if different build-time configurations could lead to vulnerability in the tor network. If there is the slightest doubt about that, I will remove this ebuild at once or fix it.
I'm not a browser dev, but I don't think this shouldn't be an issue. As long as the ebuild uses all of the security patches and extensions, it shouldn't be a problem. Also, if any vulnerabilities are introduced by this ebuild, it would only harm the user's anonymity and should not have an impact on the network.
Hmm, thanks for the evaluation. Where could I get a second opinion on this? cheers, hasufell -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEbBAEBAgAGBQJQO/2QAAoJEFpvPKfnPDWzZXgH90mR3LGqjPJPxcYARHN95Dwp jyPEGLGHg01cZgtP3lhO6lcSMkgSGr2Jd004mvK56PkEjahBgq1PZCyVJdxW+HQQ AlU4gCjIt5IdQayDAcrtyWNx/eMAVWq+oVPjb9KvSlPd9mlTM/ukjGYxCYQk2Qf1 1Kyp4yOudRs8UqtTzpVezav8/PsWNHBbH1slR0Ryu6kK6OSmvkySraR8XapkjLxB YODtw5rFAi+8DmG46jKxXVIg5IFe8ErAiX3XIxqkqRGR/jEv4tCfrtWXpWJeX8dN 785vxSFW6deJkMFP4Vs4YCbmdnFQ5JcTq3ToIfnJ3oIOHu3rsNpO7E2J9JkcsA== =IiHr -----END PGP SIGNATURE-----
participants (3)
-
julian -
Mansour Moufid -
Matthew Finkel