GNU Guix and Tor Browser Packaging
There is a serious Tor Browser packaging effort [3][4] being done by ng0 (GNUnet dev) for the GNU Guix [0] package manager. GNU Guix supports transactional upgrades and roll-backs, unprivileged package management, per-user profiles and most importantly reproducible builds. I have checked with Guix's upstream and they are working on making a binary mirror available over a Tor Hidden Service. [2] Also planned is resilience [2] to the attack outlined in the TUF threat model. [1] Back to the topic of Tor Browser packaging. While there are good reasons for Debian's pakaging policies they make packaging of fast evolving software (and especially with TBB's reliance on a opaque binary VM for builds) impractial. Both we and Micah have been doing a good effort to automate downloading and validating TBB but I still believe its a maintenance burden and Guix may be a way out of that for Linux distros in general. What are your thoughts on this? *** [0] https://www.gnu.org/software/guix/ [1] https://github.com/theupdateframework/tuf/blob/develop/SECURITY.md [2] https://lists.gnu.org/archive/html/guix-devel/2017-03/msg00192.html [3] https://lists.gnu.org/archive/html/guix-devel/2017-03/msg00189.html [4] https://lists.gnu.org/archive/html/guix-devel/2017-03/msg00149.html
bancfc@openmailbox.org transcribed 1.9K bytes:
There is a serious Tor Browser packaging effort [3][4] being done by ng0 (GNUnet dev) for the GNU Guix [0] package manager. GNU Guix supports
Eh, now that the cat is out of the bag (cat's don't belong into bags anyway), I think I have to do this now and not on my own conditions. Hi! As I told bancfc somewhere else, I've had a short contact with the trademarks team of torproject. I will get back to you when someone was able to identify issues in torbrowser which might lead to modifications of torbrowser (for more details I just hope trademarks@tp.o can communicate it to you) because all packaged software which is included in upstream of Guix (master) must follow the GNU Free System Distribution Guidelines. I hope that I have to make as little modifications as possible as I I am aware that the fingerprint of the browser could change depending on the kind of changes. I hope to get back to this task in about 3 weeks, right now I'm busy with getting more documentation done for another project.
transactional upgrades and roll-backs, unprivileged package management, per-user profiles and most importantly reproducible builds. I have checked with Guix's upstream and they are working on making a binary mirror available over a Tor Hidden Service. [2] Also planned is resilience [2] to the attack outlined in the TUF threat model. [1]
Back to the topic of Tor Browser packaging. While there are good reasons for Debian's pakaging policies they make packaging of fast evolving software (and especially with TBB's reliance on a opaque binary VM for builds) impractial. Both we and Micah have been doing a good effort to automate downloading and validating TBB but I still believe its a maintenance burden and Guix may be a way out of that for Linux distros in general.
What are your thoughts on this?
***
[0] https://www.gnu.org/software/guix/ [1] https://github.com/theupdateframework/tuf/blob/develop/SECURITY.md [2] https://lists.gnu.org/archive/html/guix-devel/2017-03/msg00192.html [3] https://lists.gnu.org/archive/html/guix-devel/2017-03/msg00189.html [4] https://lists.gnu.org/archive/html/guix-devel/2017-03/msg00149.html _______________________________________________ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Hi folks, as your trademarks team / person suggested to me I get in touch with the dev team of torproject. While I'm more involved in GNUnet, I work at the intersection of projects. Currently this means I'm involved in system integration. At Guix we are interested in working closer with projects like tor, TAILS, Whonix and the like. Porting torbrowser is not only in the interest of the Guix community but also in the interest of Wonix who recently expressed interest in selectively using Guix for their work. For me as maintainer of the system (in development) pragmaOS it also means that we can decide between icecat OR torless torbrowser for proxied GNUnet connections. I'm interested in your response to the actions listed below and wether you think this will still qualify as torbrowser or what other option you propose for us at Guix to use. "Option" here means that I am not sure what other graphical theme you have for versions of the browser which do not use the trademark when they can (logically) also not use the firefox trademarks. I would reflect in the description of the package that it is not torbrowser but a reconstruction of the way torbrowser is build, tracking upstream as closely as possible while removing (list of features which were removed goes here). This can be compared to what the inoffical Gentoo maintainer does in the .ebuild file here: https://data.gpo.zugaina.org/torbrowser/www-client/torbrowser/ My request here is just in the position as a contributor to Guix, not for pragmatique (the project which works on pragmaOS etc), Whonix, GNUnet or any other project I mentioned before. Thanks in advance. Now the content I've been talking about: It looks like the changes I need to make to torbrowser are not so grave at all. Someone pointed me to the gnu-linux-libre@nongnu.org list to reach out to other FSDG systems. The thread can be reviewed here: https://lists.nongnu.org/archive/html/gnu-linux-libre/2017-03/msg00002.html Basically: I will need to discourage Mozilla leftovers: - the mozilla addon service will be overwritten, in other words: Where you would find https://addons.mozilla.org/ at "Preferences > AddOns" it will be replaced by the thing Icecat points to. Longterm plan is to offer firefox extensions native through "guix package -i youraddonnamehere". Privacy / Tracking reasons: - Firefox "Sync" will be disabled. - Google will be removed from the search plugins if I understood the procedure correctly (at least it is not in Icecat) A question directly for torbrowser team: - about:license does not list licenses the torbrowser project uses, only firefox. Why? DRM - Luke from parabola mentioned that drm has been enabled in recent versions of torbrowser. This needs to be removed aswell. https://git.parabola.nu/abslibre.git/tree/libre/iceweasel/vendor.js#n23 https://git.parabola.nu/abslibre.git/tree/libre/iceweasel/mozconfig#n39 https://gitweb.torproject.org/tor-browser.git/tree/browser/app/profile/firef... ng0 transcribed 3.4K bytes:
bancfc@openmailbox.org transcribed 1.9K bytes:
There is a serious Tor Browser packaging effort [3][4] being done by ng0 (GNUnet dev) for the GNU Guix [0] package manager. GNU Guix supports
Eh, now that the cat is out of the bag (cat's don't belong into bags anyway), I think I have to do this now and not on my own conditions.
Hi!
As I told bancfc somewhere else, I've had a short contact with the trademarks team of torproject. I will get back to you when someone was able to identify issues in torbrowser which might lead to modifications of torbrowser (for more details I just hope trademarks@tp.o can communicate it to you) because all packaged software which is included in upstream of Guix (master) must follow the GNU Free System Distribution Guidelines. I hope that I have to make as little modifications as possible as I I am aware that the fingerprint of the browser could change depending on the kind of changes.
I hope to get back to this task in about 3 weeks, right now I'm busy with getting more documentation done for another project.
transactional upgrades and roll-backs, unprivileged package management, per-user profiles and most importantly reproducible builds. I have checked with Guix's upstream and they are working on making a binary mirror available over a Tor Hidden Service. [2] Also planned is resilience [2] to the attack outlined in the TUF threat model. [1]
Back to the topic of Tor Browser packaging. While there are good reasons for Debian's pakaging policies they make packaging of fast evolving software (and especially with TBB's reliance on a opaque binary VM for builds) impractial. Both we and Micah have been doing a good effort to automate downloading and validating TBB but I still believe its a maintenance burden and Guix may be a way out of that for Linux distros in general.
What are your thoughts on this?
***
[0] https://www.gnu.org/software/guix/ [1] https://github.com/theupdateframework/tuf/blob/develop/SECURITY.md [2] https://lists.gnu.org/archive/html/guix-devel/2017-03/msg00192.html [3] https://lists.gnu.org/archive/html/guix-devel/2017-03/msg00189.html [4] https://lists.gnu.org/archive/html/guix-devel/2017-03/msg00149.html _______________________________________________ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
-- PGP and more: https://people.pragmatique.xyz/ng0/
participants (2)
-
bancfcï¼ openmailbox.org -
ng0