<mark_weaver>jxself: why did you revert linux-libre back to 3.16.1 ?
<jxself>mark_weaver: I jumped the gun. I compiled 3.16.2 for my public repository using the deblob scripts and later on updated Guix, but I didn't think to check if lxo had actually pushed 3.16.2 tarballs yet. He has not.
<jxself>So I reverted it to about breakage, since it'll 404 for now. :)
<mark_weaver>we might consider doing the deblobbing ourselves, using a snippet.
<jxself>Maybe. Would that mean people not using substitutes would download the kernel from kernel.org though? Would mean they're downloading non-free software.
<mark_weaver>true, but I thought it was decided that it was acceptable to remove non-free software in upstream code by way of snippets.
<mark_weaver>so the result of "guix build -S" includes only free code
<jxself>Hmm. Perhaps I didn't fully understand the nature of that solution then. But they also only fetch source and do nothing else right?
<mark_weaver>the 'origin' derivation would fetch the upstream source, run the debblob script, apply any patchers, and then pack it back up.
<mark_weaver>the source of the 'linux-libre' package is then the debblobbed source.
<jxself>The deblob script is being run on the user's computer though when compiling from source right? That makes me uncomfortable.
<jxself>If that's what was suggested when this was originally discussed, then I clearly didn't fully understand it... :(
<mark_weaver>I think the idea is that we in the free world need these debblobbing mechanisms, and they are even automated on machines like gnewsense servers and lxo's machines. I think there is value in my being able to do that deblobbing on my own machine instead of relying on some other server to do it for me.
<mark_weaver>there are also several other packages that include some non-free bits but for which there is no free variant available for download.
<mark_weaver>so the question is, how do we handle those packages in guix?
<mark_weaver>if you want to build the package from source but rely on hydra to build the deblobbed source, then you can do "guix build -S <package>; guix build <package> --no-substitutes"
<mark_weaver>do you think it's bad to distribute deblobbing scripts to enable users to easily do the deblobbing themselves? if you think that's okay, why is it bad for guix to make it easy for users to do it?
<mark_weaver>(btw, I'm not trying to be combative, and I respect your opinion. just trying to understand)
<mark_weaver>jxself: if we were to implement what you seem to want, I guess it would involve essentially forcing substitutes to be enabled for some subset of package sources.
<mark_weaver>would you also want us to remove the code that does the deblobbing from the guix repo, and instead keep that in a different repo that we'd use only for hydra?
<jxself>For one there's a difference between what people do on their own and what the distro does.
<mark_weaver>if hydra's key was installed by default, so that the fully free source would be downloaded from hydra by default with no special action needed by the user, would that be sufficient to address your concerns?
<mark_weaver>I guess what I'd like to know is: how inconvenient do we have to make it for users to do the deblobbing themselves? is it okay to include the deblobbing recipes in the distributed guix? is it okay to publish them in another repo? should we keep those recipes private?
<jxself>If enabling hyra by default meant that people get the already-deblobbed source code then I think so.
<mark_weaver>jxself: well, one issue is that, like any part of the build process for our core software, deblobbing is a security-critical process. if we trust a single set of machines to do that job for everyone, and don't provide an easy way for people to independently verify them, then we are making ourselves vulnerable to hacks on those machines.
<mark_weaver>guix promises to eventually make it easy for people to gain confidence in the builds by making it very easy for people to do all the build steps independently and then comparing them to the ones we distribute.
<mark_weaver>I think it's important that deblobbing security critical software be included in the set of things that we encourage independent verification of
<mark_weaver>I don't think that providing convenient automated recipes to deblobbing constitutes "directing" people to non-free software in any meaningful sense.
<mark_weaver>I think that language is talking about things like the kernel reporting the name of a non-free firmware file, or web browsers suggesting installing some non-free software. those are things that actually encourage people to use non-free software.
<jxself>Releases are cryptographically signed, just as with kernel.org. It really is just a drop-in replacement. Isn't the same issue presented by using kernel.org? People still have to trust it.
<jxself>And if the tarball were downloaded from fsfla.org instead of kernel.org can't people still repeat the same process and still get that same independent verification? I don't understand why it would be necessary for someone to download the non-free software as a prerequisite in order to verify that they and hydra both have the same thing.
<mark_weaver>regarding your first point, by that argument there is no advantage to independently verifying binary builds, because debian's binaries are cryptographically signed, and no matter what you always have to ultimately trust some source code you downloaded.
<mark_weaver>there is a chain that you must trust every link of here.
<mark_weaver>there is a great benefit to starting from as early on that chain as you can, and encouraging independent verification of as many of the build steps as you can.
<mark_weaver>jxself: I don't understand your second message. how can someone independently verify the linux-libre deblobbing process without downloading the upstream linux?
<mark_weaver>jxself: what do you suggest we do about gmsh, for example. the upstream tarball of gmsh contains non-free software. currently, we remove that in our snippet, which means that if users build gmsh without substitutes, they will download the non-free software and then immediately delete the non-free code.
<jxself>No, that wasn't what I was saying about crypgraphic signatures. Rather, it's one more data point for verification because at present it's computationally infeasible for an adversary to both modify the tarball and still have the signature match. If a project provides GPG signatures, are these checked? Seems like it's a good policy to do so if it's not done currently.
<jxself>The idea was that if 600 people are downloading linux-libre-3.16.2-gnu.tar.xz and all going through the same build recipe and all end up with the same results, isn't it likely that they're all in possession of the same stuff?
<jxself>Or change 600 to whatever other number you want. :)
<jxself>And moreover they also see they're getting the same results as the distro.
<mark_weaver>if all of those people who independently check start with the output of lxo's deblobbing process, then there is no independent verification of that deblobbing process. his cryptographic signature does only so much. if someone else manages to steal his private key (reasonably likely), or compromises the machine that runs the deblob script, then we are vulnerable to that.
<jxself>We're vulerable to kernel.org being compromised, which has happened before.
<mark_weaver>that's true, independently verifying build steps does not solve all security problems, only some of them.
<jxself>And it's not as if his deblobbing process is a secret black box. The scripts are available to the public. My only objection is that distros shouldn't be having people download non-free software. It just seems wrong. :)
<jxself>And I apply the same standard to gmsh. It seems that I didn't fully understand what civodul was proposing when he proposed it.
<jxself>I think most if not all of the FSF-endorsed distros have hosted their own source code, which means they're in a position to be able to modify it and then host their own modified versions.
<jxself>Trisquel uses helpers for example so that the source taken from Ubuntu is modified in an automated way. Then their tarball is hosted on their machine, and no one downloads non-free stuff.
<jxself>And people using the distro don't need to use the helpers. They do the usual apt-get source foo and it grabs Trisquel's modified version.
<mark_weaver>and "guix build -S", like "apt-get source", also results in our modified version, and the intended default behavior is to download that from hydra. but it seems that we are going around in circles, so maybe I should let you talk to civodul about your concerns and see what comes of it.
<jxself>Yeah, we do and I'm not the one to make the decision anyway. Whatever method gets used is ultimately decided by the FSF as to its appropriateness for endorsement.
<jxself>Oh, a thought of one difference I had during dinner: In the case of Trisquel I can manually go to the place they told me of (their repository) and the tarball I get is still free software. In this other case with Guix if I go there manually and grab that same tarball I end up with non-free software.
<mark_weaver>suppose we do as you suggest. suppose we arrange to have our own server provide 100% free source tarballs of all packages whose upstream source contains non-free software.
<mark_weaver>the natural way for us to implement this would be to make package recipes that automatically create our freed versions based on the upstream ones.
<jxself>Oh, and the hash would probably need updating too.
<jxself>I'm not saying that the methods use to make those modifications need to be secret, like just I've not said that lxo should go hide his deblobbing scripts.
<mark_weaver>well, think about how packages would be updated in such a regime. consider gmsh. when a new version comes out, how would a volunteer contributor to guix handle its update.
<mark_weaver>if he's going to put in a URL to a tarball on ftp.gnu.org, then someone with privileges is going to have to arrange to produce an updated deblobbed tarball and upload it there, before an updated recipe can even be tested.
<mark_weaver>but we don't need to handle it that way, because we already have all the needed infrastructure to handle this automatically.
<jxself>In Trisquel the process is mostly automated: The helper pulls in the version from upstream (Ubuntu in this case but it can be set it grab something from anywhere), proceed to bash it into shape, and then store the updated source code on the Trisquel servers. That source code is later grabbed by a different process and compiled. The Helper only needs modification or intervention if something goes wrong. People using the distro and not actively invol
<jxself>So I could imagine a similiar process for Guix where an automated process is involved (including checking for new versions) and making the appropriate modifications.
<jxself>But ultimately I suppose you're right that the freeing needs to be done before being delivered to people. Saying you must download this non-free software plus user-executed freedom patch seems wrong headed to me.
<mark_weaver>when did I suggest distributing proprietary software?
<mark_weaver>and who said anything about "you must"? [download this non-free software]. again, the intended default is to use substitutes, including for the freed source tarballs.
<jxself>And the substitutes mean the binary is freed (to whatever extent that makes sense.) But the distribution of proprietary software is what this whole conversation has been about right? The distro getting people to download proprietary software. The argument in favor of it seems to be that it's okay because there is also a user-executed freedom patch to fix it.
<jxself>I'd rather go further and not have that be necessary in the first place.
<mark_weaver>jason, please remember that you're talking to someone who used the XO-1 as his primary development machine, followed by the YeeLoong, so that I could avoid running a non-free BIOS.
<jxself>Yes, and so I don't understand why you're okay with having people download proprietary software if that can be avoided in the first place.
<jxself>But maybe I should just let this go. I don't want to upset anyone and I'm a little frustrated over the whole topic.
<philed>Guile/guix complete beginner here (former common lisper): Can I mess around with the guix api from the REPL? (use-modules (gnu)) comes back with "no code for module..." Do I need to change my %load-path?
<davexunit>found out that my minetest patch has a silly mistake in it when I sent it upstream. :(
<DusXMT>I'm still working on darn abiword... I know I keep saying that `I'm getting close' all the time, but this time I really am, the program compiles and runs file, but the plugins don't yet, so after I fix most of them, it'll go up
<philed>My favourite thing about programming in general is the never-ending feeling that you are getting close.
<mark_weaver>DusXMT: for those who want to make proprietary software and deny others freedom for their own benefit, yes, it must look like a plague.
<Ulrar>mark_weaver: That's also true for people who just want to use the BSD license for example
<DusXMT>mark_weaver: not just to makers of propriotary software, but to makers of permissively-licensed projects too. But I guess there are consequences to strongly protecting freedoms
<mark_weaver>well, the "benefit" to permissive licensing is that it can be incorporated into proprietary software.
<DusXMT>Can I ask a packaging question? Abiword comes with a lot of plugins, many of which impose additional dependencies. Would it be okay to also include another package, based on abiword, (eg. abiword-light) with the plugins disabled?
<DusXMT>I think I'll ask on the ML later, I still have some fixing to do before the entire thing builds... and the worst part, this computer being a pentium 3 based one, it takes over 2 hours...
<mark_weaver>we already have emacs-no-x-toolkit, although that package has another rationale besides being lighter: the gtk version of emacs cannot survive after an X server it ever connected to is shut down, whereas the non-gtk version can.