unofficial mirror of guix-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: ng0 <ng0@we.make.ritual.n0.is>
To: guix-devel@gnu.org
Subject: Re: Tor Browser
Date: Fri, 24 Jun 2016 17:49:13 +0000	[thread overview]
Message-ID: <20160624174913.GA19633@shadowwalker> (raw)
In-Reply-To: <87por637vi.fsf_-_@gnu.org>

On 2016-06-24(05:48:49PM+0200), Ludovic Courtès wrote:
> ng0 <ng0@we.make.ritual.n0.is> 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 https://git.torproject.org/tor-browser.git
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
https://archive.torproject.org/tor-package-archive/${PN}/${TOR_PV}or
https://dist.torproject.org/${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" (patch)
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)
configure:
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
contact:
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
LICENSE="BSD CC-BY-3.0 MPL-2.0 GPL-2 LGPL-2.1"
--
♥Ⓐ ng0
For non-prism friendly talk find me on
psyced.org / loupsycedyglgamf.onion

  reply	other threads:[~2016-06-24 17:49 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-06-23 10:41 patches question ng0
2016-06-23 11:09 ` Andreas Enge
2016-06-23 11:30   ` ng0
2016-06-23 20:14     ` Andreas Enge
2016-06-23 22:18       ` ng0
2016-06-23 13:23 ` ng0
2016-06-23 20:27   ` Andreas Enge
2016-06-24 12:09   ` Ludovic Courtès
2016-06-24 13:43     ` ng0
2016-06-24 15:48       ` Tor Browser Ludovic Courtès
2016-06-24 17:49         ` ng0 [this message]
2016-06-26 10:05           ` Ludovic Courtès
2016-06-29 12:48             ` ng0
2016-06-30 10:29               ` Ludovic Courtès
2016-06-30 16:09                 ` ng0
2016-06-30 18:00                 ` ng0
2016-08-05 13:35                 ` ng0
2016-08-06  4:05                   ` Alex Vong
2016-08-06 11:14                     ` ng0
2016-08-08  8:03                       ` Alex Vong
2016-08-10 20:01                         ` Mark H Weaver
2016-08-11  8:51                           ` ng0

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://guix.gnu.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20160624174913.GA19633@shadowwalker \
    --to=ng0@we.make.ritual.n0.is \
    --cc=guix-devel@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/guix.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).