-----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:
- 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:
- 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
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:
- 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:
- 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
-
julian -
Mansour Moufid -
Matthew Finkel