From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp0.migadu.com ([2001:41d0:303:5f26::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms8.migadu.com with LMTPS id WMCeKg16e2X4vQAAkFu2QA (envelope-from ) for ; Thu, 14 Dec 2023 22:56:29 +0100 Received: from aspmx1.migadu.com ([2001:41d0:303:e224::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp0.migadu.com with LMTPS id iGEDJw16e2VlegEAqHPOHw (envelope-from ) for ; Thu, 14 Dec 2023 22:56:29 +0100 X-Envelope-To: larch@yhetil.org Authentication-Results: aspmx1.migadu.com; dkim=fail ("headers rsa verify failed") header.d=riseup.net header.s=squak header.b="h/u35wJM"; spf=pass (aspmx1.migadu.com: domain of "guix-patches-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="guix-patches-bounces+larch=yhetil.org@gnu.org"; dmarc=fail reason="SPF not aligned (relaxed)" header.from=riseup.net (policy=none) ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1702590989; h=from:from:sender:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding:resent-cc: resent-from:resent-sender:resent-message-id:in-reply-to:in-reply-to: references:references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:dkim-signature; bh=lgR0pn1KULEFRD/1hMtLfTybuS2eKhAMlJWr+CjJ1tc=; b=aZsFe/fqJaA1MwlDSjp15c699GFeMmFtUFPlVTzgVLYj9my5DLFc+fpv1MR5hLno6JsKtE d6KCZXUAsIH+w6UIdZv+hd5UYK4DMnQR4uCbHnEORQaG96iJnzPEF9abGTx2OFlzz/KIrt z2VLyxOleIBXYsoNv131uk1L1VrRcOP6mHxUKExJ9f3h1SjU4NN+6EgJjd0n8SIcTuF6Ih 3iKnRuKptTIuyQhxkWNf7E8uN+cI8QyOwpDjqYFX05KMXYWBjJLLJnCXH4jOYGe1VN+y7D 0EzzL7FEDpf/G/1sPAdBw+K4XHn4X1SmwjYc9Bk9mCz2XHP7JY4x2fyjp4haoQ== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1702590989; a=rsa-sha256; cv=none; b=e/ThlvL1qjfFThA1HjBzOEbfnqZgj512xtoZGeSMWaLgKw9X1hiTrs1EvzSgjAlzCdk2hH VrWA0LunwfVJg2GkXIXXpINTZz+tQpKDf1L0E0feQ11wh6M4HvEMfF+2X7vvvNshn9PxnF 2fk07MPSnCoEnkvqm4Txc4T/BTBLbMuw7QEodYmSgy8nh9dLXSm+HMH1S0Kj6xpoOqB8zD tgp6K5Fn6A8JwqpOgvvN+hnC1epCCUu+PxczmAgBXJ/XtoWEoEWAE979mV32I9YqGNtROY rISf33dmULaN2GY+LG3ywPUSZcp668jPCNwUOrnlq62FarInbdeSjwEaWDMdqA== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=fail ("headers rsa verify failed") header.d=riseup.net header.s=squak header.b="h/u35wJM"; spf=pass (aspmx1.migadu.com: domain of "guix-patches-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="guix-patches-bounces+larch=yhetil.org@gnu.org"; dmarc=fail reason="SPF not aligned (relaxed)" header.from=riseup.net (policy=none) Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by aspmx1.migadu.com (Postfix) with ESMTPS id 1C0C414C02 for ; Thu, 14 Dec 2023 22:56:29 +0100 (CET) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rDtge-0003Mi-FS; Thu, 14 Dec 2023 16:56:08 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1rDtgZ-0003MZ-CU for guix-patches@gnu.org; Thu, 14 Dec 2023 16:56:03 -0500 Received: from debbugs.gnu.org ([2001:470:142:5::43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1rDtgZ-0005Ry-3h for guix-patches@gnu.org; Thu, 14 Dec 2023 16:56:03 -0500 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1rDtgY-0005V6-I7 for guix-patches@gnu.org; Thu, 14 Dec 2023 16:56:02 -0500 X-Loop: help-debbugs@gnu.org Subject: [bug#42380] [PATCH] gnu: Add torbrowser. Resent-From: =?UTF-8?Q?Andr=C3=A9?= Batista Original-Sender: "Debbugs-submit" Resent-CC: guix-patches@gnu.org Resent-Date: Thu, 14 Dec 2023 21:56:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 42380 X-GNU-PR-Package: guix-patches X-GNU-PR-Keywords: To: =?UTF-8?Q?Cl=C3=A9ment?= Lassieur Cc: Raghav Gururajan , Ludovic =?UTF-8?Q?Court=C3=A8s?= , Maxime Devos , Efraim Flashner , Leo Famulari , 42380@debbugs.gnu.org Received: via spool by 42380-submit@debbugs.gnu.org id=B42380.170259090421063 (code B ref 42380); Thu, 14 Dec 2023 21:56:02 +0000 Received: (at 42380) by debbugs.gnu.org; 14 Dec 2023 21:55:04 +0000 Received: from localhost ([127.0.0.1]:51084 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rDtfb-0005Te-G6 for submit@debbugs.gnu.org; Thu, 14 Dec 2023 16:55:04 -0500 Received: from mx0.riseup.net ([198.252.153.6]:54772) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rDtfX-0005T1-8N for 42380@debbugs.gnu.org; Thu, 14 Dec 2023 16:55:02 -0500 Received: from fews02-sea.riseup.net (fews02-sea-pn.riseup.net [10.0.1.112]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mx0.riseup.net (Postfix) with ESMTPS id 4SrmNY5ysrz9typ; Thu, 14 Dec 2023 21:54:53 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=riseup.net; s=squak; t=1702590894; bh=VIDpvgz7qbvG5+WftqKTL8o/Av4rEjKhQiJc/bMjXY8=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=h/u35wJMphKOpGswB/2kV0Kf8wk22mYj5+EQJDfOjc8qIIUxxuuYDOEtTGIjkVa4t Y0oymqhP4lNsYnn8N0wpUpt+G+veVe3f+liunnCI9zya+gmimtKF3Iht6oYeFeShuP 7uaG7HXXD9BSewupTKXAk5zQTpzXZFiuZLpz6OSs= X-Riseup-User-ID: 316643CB95485C6E4D7E0893779861C8483DF6CB72663A7B5E3264B3C94D8CD5 Received: from [127.0.0.1] (localhost [127.0.0.1]) by fews02-sea.riseup.net (Postfix) with ESMTPSA id 4SrmNX41SzzFpl4; Thu, 14 Dec 2023 21:54:52 +0000 (UTC) Date: Thu, 14 Dec 2023 18:54:48 -0300 From: =?UTF-8?Q?Andr=C3=A9?= Batista Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: guix-patches@gnu.org List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-patches-bounces+larch=yhetil.org@gnu.org Sender: guix-patches-bounces+larch=yhetil.org@gnu.org X-Migadu-Flow: FLOW_IN X-Migadu-Country: US X-Migadu-Spam-Score: -4.69 X-Spam-Score: -4.69 X-Migadu-Queue-Id: 1C0C414C02 X-Migadu-Scanner: mx12.migadu.com X-TUID: UN0rBjVz3u1W Hi Clément, ter 12 dez 2023 às 12:21:18 (1702394478), clement@lassieur.org enviou: > > Hi, this is a package for Tor Browser. I initially wanted to base my work on > André's but I believe pretty much everything is new now. André's work helped > nonetheless, so thank you André. > Nice to see someone picking that up. Even though there were quite a lot of changes both on guix and on Tor Browser which made my package definition mostly obsolete, I should state beforehand that your code is both clearer and more concise which also means more maintainable than mine. Moreover the removal of mozilla's store was a most needed improvement. However, I do think that there are things which need to be fixed before commiting this patch. I've made some intersperced comments bellow, both to you and other reviewers. First and foremost: The noscript addon seems to be missing from the browser. If one goes to the 'about:addons' tab, it is neither listed nor manageable there. This makes the security slider almost useless and also implies that as things stand we would lead guixen to run potentialy harmful and nonfree javascript code unknowingly and without a warning. You can check that on https://coveryourtracks.eff.org for the difference between this browser fingerprint and the upstream one. Other than that, the current recipe is not deterministic. This is probably due to the 'BuildID' which is a timestamp. See: (#$output)/lib/torbrowser/platform.ini Moreover, both upstream torbrowser and guix' icecat build an internationalized browser with several locales and the browser as is offers users on startup to change or set the browser locale even though we did not provide any other than en-US. I don't think the current en-US only is a show stopper, but let's make a note on internationalizing it later. > A few notes: > - HTTPS-everywhere extension is now built-in. In my understading, the extension got removed as the feature it provided is now part of firefox itself. > - The name is "torbrowser" because it's obvious that we don't bundle anything > in Guix, that's how other distros do and it's simpler. What { is || is not } obvious is highly subjective. Maybe to most people it is obvious that the distro version of some software is not the upstream one. On the other hand, maybe it's not obvious to many that, with regards to TorBrowser's goals, this is a significative difference as it potentialy implies a reduced anonymity set. 'torbrowser-unbundle' was a pun on the original torbrowser name ("Tor Browser Bundle") and it was intended as some kind of warning to users that the guix package cannot live up to a vital upstream goal, namely that all users are using an identical browser in order to avoid, best as possible, any leak which could be used to fingerprint/deanonymize users. It was also kind of an homage to upstream directives if you will. However, even if some guix users may be unaware, this is an improvement to the current situation where people use icecat with tor which undeniably means a reduced anonymity set. Also, the hint may have been too weak to convey the intended warning. So I won't strongly oppose naming it simply 'torbrowser' if I'm the only one who sees a point on doing otherwise. > > diff --git a/gnu/packages/browser-extensions.scm b/gnu/packages/browser-extensions.scm > index 21c519eda31c..9efa94b77396 100644 > --- a/gnu/packages/browser-extensions.scm > +++ b/gnu/packages/browser-extensions.scm > @@ -21,6 +21,7 @@ > (define-module (gnu packages browser-extensions) > #:use-module (guix gexp) > #:use-module (guix packages) > + #:use-module (guix download) > #:use-module (guix git-download) > #:use-module (guix build-system copy) > #:use-module (guix build-system gnu) > @@ -221,3 +222,28 @@ (define passff > > (define-public passff/icecat > (make-icecat-extension passff)) > + > +(define noscript > + (package > + (name "noscript") > + (version "11.4.28") > + (source (origin > + (method url-fetch/zipbomb) > + (uri (string-append > + "https://noscript.net/download/releases/noscript-" version > + ".xpi")) > + (sha256 > + (base32 > + "051wawi0yjyramp743yjawqaz59g3m2gcivm24b44ibd4arpdl2l")))) > + (build-system copy-build-system) > + (properties '((addon-id . "{73a6fe31-595d-460b-a920-fcc0f8843232}"))) > + (arguments > + `(#:install-plan '(("." ,(assq-ref properties 'addon-id))))) > + (home-page "https://noscript.net") > + (synopsis "Software providing extra protection for various browsers.") > + (description "The NoScript Security Suite is a software providing extra > +protection for web browsers.") > + (license license:gpl3+))) > + > +(define-public noscript/icecat > + (make-icecat-extension noscript)) As I understand it, we are not building noscript from source, but getting a previously built which has minified JS. I never got to build it from source and also don't think this makes it uncommitable (agains FSDG), but maybe we could have a note to re-work this definition later in order to have it built from source (the guix way!). ... > diff --git a/gnu/packages/tor.scm b/gnu/packages/tor.scm > index 71f32b3f4331..31e9945f5d39 100644 > --- a/gnu/packages/tor.scm > +++ b/gnu/packages/tor.scm ... > +(define-public torbrowser > + (package > + (inherit icecat-minimal) > + (name "torbrowser") > + ;; To find the last version, browse > + ;; https://archive.torproject.org/tor-package-archive/torbrowser/ > + ;; ( is the version of the `torbrowser-assets` package). There > + ;; should be only one archive that starts with "src-firefox-tor-browser-". > + (version "115.5.0esr-13.0-1-build4") Is there any reason why you chose to use the 'src' version, instead of the TorBrowser release version (aka torbroser-assets one). At first I think it would be better if our version were the same as upstream as it would be clearer to both users and maintainers which version guix is offering without installing it. Besides, are you sure this src version number is guaranteed to be progressive towards higher numbers? Decomposing it: Firefox version | tb build ver | tb build attempt 115.5.0esr | 13.0-1 | build4 FF version: always increases, but not necessarily in the same step as torbrowser releases; tb build version: usually remains the same throughout a major torbrowser release series; tb build attempt: varies with the release process and sometimes it decreases. > + (source > + (origin > + (method url-fetch) > + (uri > + (string-append > + "https://archive.torproject.org/tor-package-archive/torbrowser/" > + (package-version torbrowser-assets) > + "/src-firefox-tor-browser-" version ".tar.xz")) > + (sha256 > + (base32 > + "0p0qsfc2l2bicqjr1kxciiij5qz7n8xqyvyn8f13fvk0wyg94c6v")))) > + (build-system mozilla-build-system) > + (arguments > + (substitute-keyword-arguments (package-arguments icecat-minimal) > + ((#:configure-flags flags '()) > + #~(cons* > + "--without-relative-data-dir" ;store is read-only Shouldn't we also set '--with-user-appdir=.torbrowser' ? There is a comment on 'src/browser/config/mozconfigs/tor-browser' that says we need to set this flag when the relative data dir is unset. > + "--disable-base-browser-update" > + "--enable-update-channel=release" Does this mean that users get notified when there is a new torbrowser release upstream? Shouldn't this flag be removed? > + "--with-branding=browser/branding/tb-release" > + (string-append "--prefix=" #$output) > + (string-append "--with-base-browser-version=" > + #$(package-version > + (this-package-input "torbrowser-assets"))) > + #$flags)) > + ((#:phases phases) > + #~(modify-phases #$phases > + (add-before 'configure 'setenv > + (lambda _ > + (setenv "CONFIG_SHELL" (which "bash")) > + ;; Install location is prefix/lib/$MOZ_APP_NAME. Also > + ;; $MOZ_APP_NAME is the executable name. Default is > + ;; "firefox". > + (setenv "MOZ_APP_NAME" "torbrowser") > + ;; Profile location (relative to "~/."). Default is > + ;; lower($MOZ_APP_VENDOR/$MOZ_APP_BASENAME), which is: > + ;; ~/.tor project/firefox. > + (setenv "MOZ_APP_PROFILE" "torbrowser/browser") > + ;; WM_CLASS (default is "$MOZ_APP_NAME-$MOZ_UPDATE_CHANNEL"). This comment was unclear for me at first, probably due to my own ignorance. To the benefit of others, this is in line with instructions on 'src/browser/config/mozconfigs/tor-browser' as a hint to window managers on GNU/Linux. > + (setenv "MOZ_APP_REMOTINGNAME" "Tor Browser") > + ;; Persistent state directory for the build system (default is > + ;; $HOME/.mozbuild). > + (setenv "MOZBUILD_STATE_PATH" > + (in-vicinity (getcwd) ".mozbuild")))) ... > + (lambda () > + (format #t "// first line must be a comment~%") > + ;; Locking prevents these values being written to > + ;; prefs.js, avoiding Store path capture. > + (format #t "lockPref(~s, ~s);~%" > + "extensions.torlauncher.torrc-defaults_path" > + (in-vicinity > + lib "TorBrowser/Data/Tor/torrc-defaults")) > + (format #t "lockPref(~s, ~s);~%" > + "extensions.torlauncher.tor_path" > + (search-input-file inputs "bin/tor")) This has the undesired side-effect of making impossible to run TorBrowser with a shepherd tor instance. Is it really needed? Besides the inefficiency of running two tor processes, using a single one has the benefit of making eventual onion service auth keys available both on the browser and to other user software on the same location. > + ;; Required for Guix packaged extensions > + ;; SCOPE_PROFILE=1, SCOPE_APPLICATION=4, SCOPE_SYSTEM=8 > + ;; Default is 5. ... > + (replace 'install-desktop-entry > + (lambda _ > + (let ((apps (in-vicinity #$output "share/applications"))) > + (mkdir-p apps) > + (make-desktop-entry-file > + (in-vicinity apps "torbrowser.desktop") > + #:name "Tor Browser" > + #:exec > + (format #f "~a %u" (in-vicinity #$output "bin/torbrowser")) Why do away with the 'start-tor-browser.sh'? Part of the logic there is redundant or not necessary on a system install, but not everything. > + #:comment > + "Tor Browser is +1 for privacy and -1 for mass surveillance" > + #:categories '("Network" "WebBrowser" "Security") > + #:startup-w-m-class "Tor Browser" > + #:icon "tor-browser")))) > + (replace 'install-icons > + (lambda* (#:key inputs #:allow-other-keys) > + (for-each > + (lambda (size) > + (let ((oldpath (string-append > + "browser/branding/tb-release/default" > + size ".png")) > + (newpath (string-append #$output > + "/share/icons/hicolor/" > + size "x" size "/apps"))) > + (mkdir-p newpath) > + (copy-file oldpath > + (in-vicinity newpath "tor-browser.png")))) > + '("16" "22" "24" "32" "48" "64" "128" "256")))))))) > + (inputs > + (modify-inputs (package-inputs icecat-minimal) > + (append bash-minimal > + tor Why not tor-client instead? I don't see a legitimate use case of running relays on the torbrowser. Also, shouldn't this be a propagated input so as to not be garbage collected? > + torbrowser-assets))) > + (propagated-inputs > + (list noscript/icecat)) This appears to be insufficient. See comments above. Thanks for your work on guix and cheers!