[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Tor Browser

From: ng0
Subject: Re: Tor Browser
Date: Fri, 24 Jun 2016 17:49:13 +0000

On 2016-06-24(05:48:49PM+0200), Ludovic Courtès wrote:
> ng0 <address@hidden> skribis:
> > On 2016-06-24(02:09:39PM+0200), Ludovic Courtès wrote:
> [...]
> >> > (define-public firefox
> >> >   (package
> >> >     (name "firefox")
> >> >     (version "45.2.0esr")
> >>
> >> What is the goal here?
> >>
> >> Guix proper can provide IceCat (which modifies Firefox to comply with
> >> trademark rules, to comply with the GNU FSDG¹, and to enhance privacy),
> >> maybe Tor Browser (assuming it complies with the FSDG as well), but not
> >> stock Firefox (unless the trademark issue and FSDG violations are
> >> resolved.)
> >
> > Writing a base for torbrowser
> Great!  Then I think you don’t need to worry about Firefox at all.
> Maybe TB uses Firefox’s source and then patches it, but that doesn’t
> mean we need a Firefox package.
> >> Besides, I think it should be possible to (inherit icecat) rather than
> >> duplicate all the recipe.
> >
> > True, but between 38.8 and 45.2.0 things change, patches can not be reused,
> > and the reason I gave above.
> Then use the Firefox 45 source as a starting point.

Do we have something comparable? I thought it was better to start off
with a native 45.2.0esr, leave out this part of the gitian build of
torbrowser and try to just inherit/patch it that way.

Maybe my approach is still a bit gentoo'ish. In our Gentoo overlay we
replicated the gitian build, but I was only maintaining it and ocassionaly
doing a version bump and testing, I did not come up with the procedure.

What it does is the following:

A shallow checkout of
which is usually pinned to a tag specified in the gitian build
repository of torproject for tor-browser,
pull in gentoo specific patchsets for the firefox version,
pull in an architecture specific torbrowser from either${PN}/${TOR_PV}or${PN}/${TOR_PV} (arch is x86 or amd64),
prepare the source:
1. apply firefox patches
2. revert "change the default firefox profile directory to be tbb-relative" 
3. allow the lightspark and freshplayerplugins for whatever reasons (except 
them from a blocklist)
4. fix some nss problems
5. set the plugins directory to the global one of gentoo
6. fix sandbox violations
etc etc (very similar to firefox at this point and before it)
rename install executables and directories
disable the update + set the tor-browser version
install (build):
some orientation around the tor-browser-bunde.git repository
some firefox again
set a profile
install files.

After writing this out of the context of the ebuild syntax,
I can see why it could be build without a firefox package.
However we still would need to apply what icecat does,
at least part of it, where necessary.
Yesterday I wrote phases for most of what the icecat build
bash script does.

> > I am more willing to maintain another fork of firefox than to
> > wait for icecat to be recent enough to be usable as a base for
> > a torbrowser package.
> I think there’s a misunderstanding: if Guix provides Tor Browser, then
> it should provide precisely Tor Browser, not Firecat or Icefox with 20
> patches.  :-)

" However we still would need to apply what icecat does, or "
" at least part of it. "
" Yesterday I wrote phases for most of what the icecat build "
" bash script does. "
Does this not apply here, that we need to patch torbrowser?
You can still use the mozilla store for example.

> > Additionally I was about to get in contact with torproject and
> > ask about possible trademark/confusion issues on their side,
> > the unsent email:
> I think we do not need to bother them.  AFAIK, we can use the name “Tor
> Browser” just fine, so there’s no reason to invent another name or
> anything.
> The only issue that needs to be addressed (but again, we don’t need to
> bother the Tor folks with that) is whether Tor Browser is FSDG-compliant
> (concretely, whether it recommends non-free software, for instance.)

That's why I was about to ask them. Some parts needs to be changed,
out of the same motivation why icecat exists.
Their FAQ says that they "don't want to be trademark bullies", so
a good conversation is better than a sudden surprise on both ends.

No one can be an expert in everything, and international law is
something I don't claim to be an expert in, so I seek conversation.

Aside, I wonder if crypto export laws would be applicable to
binaries of crypto software we package and some nations still
having regulations on them. And on top of that, what happens
when guix moves to secure, real distributed, peer-to-peer
package package distribution.
Not that I really care or believe that anyone is legally
responsible then, but I'm curious about the 'what if'.

A bit related offtopic now, what I inteded to write in the
email to torproject and what I discussed this year with a
It would be nice to have a modified firefox
– or anything firefox based or being an application of top
of something which uses the mozilla app+extensions store –
which uses extensions, addons, apps, coming from the guix
store, imported by compatible licenses.
And I think this would be then a case where we, in the eyes
of the developers of affected software, have altered the
application, in my view just an extension of security but
for them it could mean an irritation.

Completely source based gentoo derivates can do something
in this direction already because they only provide you
with the source, not binaries.
We also provide binaries.
Would this be a modification gone too far already? I see
it as an extension to the software.

> HTH!
> Ludo’.

For the license part:

I have not double checked myself, but our ebuild says that
the codebase of torproject is under BSD license (which
probably is inaccurate and unspecific) and icons are under
the CCPL-Attribution-3.0

# BSD license applies to torproject-related code like the patches
# icons are under CCPL-Attribution-3.0
♥Ⓐ ng0
For non-prism friendly talk find me on / loupsycedyglgamf.onion

reply via email to

[Prev in Thread] Current Thread [Next in Thread]