[Whonix-devel] GNU Guix Questions

[bancfc at openmailbox.org]

On 2017-03-10 11:44, ng0 wrote:
> bancfc at openmailbox.org transcribed 5.5K bytes:
>> On 2017-03-07 12:05, ng0 wrote:
>> > On 17-03-07 00:59:08, bancfc at 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 at 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 at 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