From mboxrd@z Thu Jan 1 00:00:00 1970 From: bancfc@openmailbox.org Subject: Re: [Whonix-devel] GNU Guix Questions Date: Mon, 13 Mar 2017 23:42:12 +0100 Message-ID: <2187346e3619a812761e9448b407528e@openmailbox.org> References: <20170306171504.q3upjno6bzbqeeqc@abyayala> <03855981cbbc72b0bac0b45345b19d4a@openmailbox.org> <20170307110551.mdham45e4ifa7dy6@abyayala> <20170310104422.fbiqiyxhqwjbzmql@abyayala> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:58709) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cnYg5-000303-Cm for guix-devel@gnu.org; Mon, 13 Mar 2017 18:43:00 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cnYg3-0006Fn-KI for guix-devel@gnu.org; Mon, 13 Mar 2017 18:42:57 -0400 In-Reply-To: <20170310104422.fbiqiyxhqwjbzmql@abyayala> List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org Sender: "Guix-devel" To: bancfc@openmailbox.org, ludo@gnu.org, whonix-devel@whonix.org, guix-devel@gnu.org, Guix-devel On 2017-03-10 11:44, ng0 wrote: > bancfc@openmailbox.org transcribed 5.5K bytes: >> On 2017-03-07 12:05, ng0 wrote: >> > On 17-03-07 00:59:08, bancfc@openmailbox.org wrote: >> > > On 2017-03-06 17:15, ng0 wrote: >> > > > Hi bancfc, >> > > > >> > > >> > > Hi ng0, great to see you here :) >> > > >> > > > On 17-03-06 16:14:08, bancfc@openmailbox.org wrote: >> > > > > Hi Guix devs, I am a privacy distro dev and we are looking at using >> > > > > Guix in >> > > > > our OS. I have a few questions: >> > > > > >> > > > > * Is the Guix package archive available from a Tor hidden service? >> > > > > There are >> > > > > many advantages of updating a system over Tor such as preventing a >> > > > > target >> > > > > adversary from fingerprinting and targeting hosts that run vulnerable >> > > > > packages and protecting systems in case the package manager has a >> > > > > security >> > > > > bug. Debian and Tor now provide onion mirrors for their packages. >> > > > > Can you >> > > > > please consider doing the same? > > Ludovic: can we get an .onion for hydra.gnu.org? I know that I asked > for > unspecific download mirrors (alpha,ftp,etc) at gnu.org (different > list), but asking > specifically about hydra.gnu.org would be different. What's left to be > documented then is how to provide access for clients. The explanations > I've got so far weren't helping. I could ask for > the GNUnet eV machine which runs mirror.hydra.gnu.org. > > bancfc: Depending on the resources Whonix has, you could consider > running your own substitutes servers (if that's an option)? > Yes we are interested in running our own substitute servers. We currently host our project specific .deb repo. Or do you mean a full mirror of hydra? > > >> > > > As far as I know this might be discussed currently at GNU >> > > > sysadministration level, >> > > > at least that's the last info I got when I suggested this last week to >> > > > RMS. >> > > > There is an onion mirror which is run by another community. It doesn't >> > > > mirror alpha.gnu.org yet (where guix binaries are located), but it plans >> > > > to do so. I need to get in touch with the community to ask wether they >> > > > would be okay with more bandwidth. >> > > > Do you have an estimation on how high your usage would be for the guix >> > > > download from the onion mirror? >> > > > >> > > >> > > >> > > The amount for bandwidth is approximately the size of GNUnet x 15K >> > > users. >> > >> > I think we have a misunderstanding here. Do you mean access to the >> > releases of Guix as in what's on >> > https://alpha.gnu.org/whatever/the/path/to/guix/was, where the software >> > itself is released, or did you mean what we call 'binary substitutes' in >> > Guix, the packages which are build from the guix.git master which >> > feature the software (here software as in tor, perl, epiphany, gnupg, >> > etc)? >> > Now that I'm reading your initial email again it reads as if could be >> > either or both. It would be good if you try to clarify this. >> > >> >> Yes I meant binary substitutes not Guix itself. >> >> > >> > > Later on we will expand the selection to include Tor Browser once you >> > > package it - if that pans out that would be a massive achievement. The >> > >> > FYI: >> > The torbrowser I am packaging initially is a 1:1 copy of what torbrowser >> > team is keeping in the git repository. Nix for example decided to >> > just patchelf the binary releases of torbrowser (the tar files found on >> > dist.torproject.org), this is not acceptable for the work for Guix. >> > So I'm trying my way with building from git tags. If there are other >> > people interested and willing to help (once I have something to debug), >> > I will share recipes / git repositories to work on it. >> >> I think this work is so important that it deserves bringing it to the >> notice >> of the Tor devs on their mailing list. They will probably help out >> because >> it is something they have been wanting to do and are interested in: >> >> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev/ > > I will get in touch later, I had some first introduction to the > trademarks team of torbrowser, now I need help in trying to figure out > what needs to be modified. After this is done I can get in touch with > tor-dev to talk about the trademark specifics. > > It can take a while, so I'd appreciate any kind of help in judging > current torbrowser and what needs to be modified. I'm busy with > documenting for 'pragmatique' to find more people to help on pragmaOS > (working title of the GuixSD blend). > Sorry I posted there before seeing your reply :/ I mentioned your packaging work on Tor-Dev: https://lists.torproject.org/pipermail/tor-dev/2017-March/011993.html > >> > Furthermore the final package version for Guix will include fixes which >> > might be needed, similar to what icecat does to firefox esr, to include >> > it in Guix. This is of course no 1:1 torbrowser then anymore and must >> > not be described as such. It'll be interesting to see if at all it >> > differs in fingerprinting from torbrowser. >> >> To check the fingerprint of your versions you can use this site: >> https://fpcentral.irisa.fr/ >> >> It was a product of a GSoC project to exclusively measure Tor Borwser >> fingerprints between versions to help TBB devs and users make sure >> they are >> safe. > > Thanks! > >> > If for any reason you need the full 1:1 copy we can talk about this once >> > I/we >> > are getting there, offlist or at least not on guix-devel@gnu.org. >> > >> >> No particular reason for 1:1 as long as the Guix package is fully >> reproducible and closely tracks upstream security updates its ok with >> us. >> >> > > Torproject have discussed packaging it for years but they couldn't >> > > work it >> > > out because of the breakneck speed of development and the cumbersome >> > > process >> > > of creating Debian packages. Meanwhile anonymity distros were forced >> > > to come >> > > up with a workaround safe downloader mechanism in absence of a package >> > > fecthable from a package manager. Its been a high maintenance effort >> > > over >> > > the years and a Guix package would finally solve this. >> > > >> > > Another "wishlist" package would be GNU-libre kernel that includes the >> > > Grsecurity patchset so we can include that out of the box instead of >> > > requiring users to manually patch and tweak settings with every >> > > (weekly) new >> > > upstream release. >> > >> > I think HEADS (the linux-libre grsec devuan based blend) did this, or >> > they >> > are working on it. I know for Guix, someone is working on SELinux. I >> > think if you are looking into getting a GRSec enabled kernel with >> > according policies, this must be answered by someone who knows more >> > about the core of Guix. >> > It might also be the case that I don't fully understand your plan. What >> > I read sounds like you are either mixing up Guix and GuixSD or as if >> > the differences between both need to be explained. It would be easier to >> > know the current state of the system, and where you want to go with >> > this. >> > >> >> I understand the difference between Guix and GuixSD - the latter is a >> full >> distribution based around the former. Since we are Debian based I was >> looking into cherry-picking packages from Guix binary repos because >> the way >> it works is ideal instead of the bureaucracy of Debian packaging >> policies >> which makes packaging impossible in some cases. >> >> > > Okay, I guess it needs to be more clear what can be used then. > As I understand it, you will not be able to use the kernel when you use > Guix on another distro. Understood