-----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