<mark_weaver>yes, it's Ludovic's key. what's wrong with that? how does that make it less secure?
<mark_weaver>someone has to be in possession of the private key material. personally, I prefer to know who that is.
<bishopj> I figured guix might have a seperate project key like tails does.
<mark_weaver>I have great respect for Jacob, but I'd be curious to see an argument for why that approach is better.
<bishopj>1) more easily allows a fully offline key
<mark_weaver>when I see a key that doesn't have a person's name on it, I wonder (1) who has copies of the private key, (2) who has the responsibility if a signed but compromised tarball is discovered.
<mark_weaver>bishopj: why does it more easily allow a fully offline key? plenty of people have personal keys that are kept on an air-gapped machine.
<bishopj>mark_weaver: it is simply more common for people to use a single gpg key for everything than to have multiple seperate gpg keys for seperate tasks on seperate systems
<mark_weaver>bishopj: consider this: the bigger problem is that you probably don't have a trust path from a key you trust to Ludovic's key.
<mark_weaver>now, Ludovic can go to keysigning events and get people to sign his key.
<mark_weaver>but should he go around and ask people to sign a "Guix distribution key" key?
<bishopj>a project key, signed by all the members of the guix team can quickly build a bigger web of trust
<mark_weaver>think about what it means for the person being asked to sign that key. signing a key means that you stand witness that the key is under the possession of a human being whose identity you know.
<mark_weaver>bishopj: we could just as easily all sign Ludovic's key, but that requires that we first meet with him in person.
<mark_weaver>but I don't know what it means exactly for me to sign a key that purports to be the "Guix distribution key". For all practical purposes, what I'm really asserting is that Ludovic has possession of that key.
<mark_weaver>anyway, feel free to post to email@example.com with your suggestions for how we could do things in a better way, along with arguments in support of it.
<mark_weaver>I'm not necessarily saying you're wrong, I just don't understand what it would be an improvement.
<bishopj>hmmm, you make a completely valid argument. However some people might feel more comfortable should an organization be the one behind the release even though through policy it is obvious the individual behind that action is.
<bishopj>aka when people hear the gnu project or the debian project verfied X
<bishopj>they give it more acceptence than John Smith verfied X
<bishopj>even though in reality it was John Smith who was responsible for the Y project Key to sign X
<mark_weaver>well, it may be true that most people put more trust in an organization than an individual, but in the case of private keys I think that's foolish.
<mark_weaver>I have much more trust in a private key that only one person has access to than one that is shared among several people.
<mark_weaver>and the actual job of preparing the tarball release is done by a real human being on one computer.
<mark_weaver>and if it turns out to be compromised, that individual must assume responsibility. none of the other people involved in the project can take responsibility for that.
<bishopj>compromising an offline key is quite a feat
<mark_weaver>what we have instead is that the GNU project appointed Ludovic as maintainer of GNU Guix, he's the one who prepares the releases, and so he's the one that signs them.
<mark_weaver>bishopj: well, I meant if the tarball release is compromised
<bishopj>You also could do a signiture chain, aka all commits are signed by the people doing the work.
<mark_weaver>keeping the private key on an airgapped machine doesn't change the fact that ultimately the tarball is derived from a source code repository that several people have write access to, and the steps of running 'autoreconf' and preparing the tarball is done by Ludovic on his machine.
<mark_weaver>bishopj: well yes, we should indeed start signing our commits in the git repo.
<bishopj>thus the project key becomes little more than a stamp saying that the commits done previously are deemed as trusted by the release process
<mark_weaver>suppose we had a project key with no human name on it. who do you think should be in possession of that private key material?
<bishopj>I say write up the process of producing release files, allocate a position to handle it and have the person doing that task make their own private key with the right details and have the previous project key sign the new key
<mark_weaver>so even though a single person has possession of the private key, you think it's a bad idea to put that person's name on the key?
<bishopj>I feel it will reduce the chances that they might use the key for anything else
<mark_weaver>as for having the previous project key sign the new key: what happens if the person in possession of the previous project key lives on the other side of the world from the person who replaces him?
<bishopj>certified mail was good enough to ship the hope diamond
<mark_weaver>wow. well, that was a different time. nowadays, when we ship our computers they are sometimes intercepted so that the NSA can implant spying devices in them.
<mark_weaver>if you are truly suggesting that postal mail could have a role here, you've lost me.
<bishopj>except keysigning can be done with printed documents that can use methods to reduce tampering
<vmlinuz88>I am running GuixSD. I've created a package definition, and I'm not sure how to test it. I've tried using the --load-path option for 'guix package', but it doesn't find the package.
<sneek>Welcome back vmlinuz88, you have 1 message.
<sneek>vmlinuz88, rekado says: Do not let anything install anything into /gnu/store/ other than Guix. To install Python packages that are not yet packaged for Guix I recommend creating a package recipe and submitting it to the ML. Python stuff is usually easily packaged.
<mark_weaver>vmlinuz88: set the GUIX_PACKAGE_PATH environment variable to point to a directory containing your *.scm file
<mark_weaver>see section 6.5 (Package Modules) of the guix manual
<luqidqanx>Hello, I'm currently using Guix SD and I'm running into a problem. I need to create a directory in "/etc/ssl/certs" but I can't. Mkdir yeilds this error when I attempt to: "mkdir: cannot create directory ‘java’: Read-only file system". How would I go about creating that directory?
<luqidqanx>The entire file-system is not read-only, it seems to be only that small part.
<mark_weaver>/etc/ssl/certs is managed by guix. the idea is that you add the 'nss-certs' package to the 'packages' section of your OS configuration, and that more generally you can choose which certificate packages to install.
<mark_weaver>and I'd like to make it easy to add your own CAs, or individual certs, as well, although I haven't done that yet.
<mark_weaver>that's the idea anyway. would that work for you? what are you needs?
<luqidqanx>I'm just trying to install the certs created by that package manually
<luqidqanx>After spending a lot of time struggling with it
<mark_weaver>well, if we do the job properly then the next user won't be faced with the same problem :)
<luqidqanx>I weep for the next user to have this problem.
<mark_weaver>luqidqanx: well, for now, you could modify your guix to not create the /etc/ssl symlink, and then you can put whatever you want there.
<mark_weaver>looking at that package, I get the impression that it's not so much about adding more certs, but rather for maintaining the JKS keystore, which I guess is just a different representation of the CA certificate database, for use by java programs. does that sound right to you?
<mark_weaver>and I personally have zero experience with java, so I'd rather leave this job for someone else.
<Anony_>rekado_: It's not actually X in the error messages, errorr basically shows (in the boot proccess) up for every flash memory device wich I have connected to the computer, the USB drive with the image on it works fine on other system, I just can't get it work on my main system.
<rekado_>this is all rather frustrating, because I haven't done anything weird. Just installed from the USB image :-/
<taylanub>civodul: hmm, in that case I can't verify whether all inputs that should be propagated are in 'propagated-inputs'. maybe instead I could make it print a notice like "make sure the following inputs are propagated: foo bar baz." or maybe it shouldn't be a build phase after all?
<civodul>taylanub: yeah i hadn't realized that, but yes, you might have to do that
<toothbrush0>Hello Guix! So, i've probably done something boneheaded, but after doing `git pull; make; make install` all commands returned errors relating to libgcrypt not being found...
<toothbrush0>I therefore (probably made stuff worse) and deleted /gnu/store/*gcrypt*, now the error is (unsurprisingly) "guix package: error: open-file: No such file or directory: "/gnu/store/ynjmfg24r0dkc47f2jfsy11kwzifw5kp-libgcrypt-1.6.3.tar.bz2.drv"".....
<taylanub>toothbrush0: one shouldn't ever touch /gnu/store, because there's a database in $localstatedir (e.g. /var/guix) which needs to be in sync with /gnu/store. not sure how your state could be restored.
<toothbrush0>Right. But it was screwed up somehow before i (stupidly) did my thing: i kept getting guile backtraces saying libgcrypt couldn't be found (including when i did `guix package -i libgcrypt`)
<mark_weaver>note that software must either be built using compiler/libs from Guix, or using compiler/libs from your host distro. mixing libs from Guix and your host distro within the same process doesn't work.
<toothbrush0>mark_weaver: hm, maybe that's a problem. i've been naively doing things without thinking about that.. till now it Just Worked™
<mark_weaver>also note that when loading a shared library using dlopen (as is done by guix for libgcrypt, iirc), if anything at all goes wrong trying to load the library, you get a "not found" type of error.
<mark_weaver>so, if guix is now built using libs from guix, and it's trying to open libgcrypt from your host system, you'd likely see an error like that.
<toothbrush0>is that very likely, considering i just went `make; make install` then a bunch of `guix package -i ...` for applications like emacs and my pdf reader?
<mark_weaver>I think it's the most probable cause of your problem. you probably started out building guix using a pure host-distro environment, and now you've added some guix stuff to it, and now you're trying to rebuild guix in a mixture of the two environments.
<toothbrush0>assuming i want to keep in another host distro, what's the best way to prevent that from happening?
<mark_weaver>when building software, you need to either completely exclude guix from the environment, or make it an exclusively guix environment.
<mark_weaver>I don't know what it means to "keep in another host distro"
<toothbrush0>so bootstrapping is complex.. or should i start with the binary tarball for guix, instead of the git version i have been using?
<taylanub>installing guix on top another distro is now a breeze with the binary/"bootstrap" tarballs, and from there you can build git checkouts of guix like: guix environment guix --pure -E './configure --prefix= --with-libgcrypt-prefix=$(guix build libgcrypt | head -n1) && make' (and it's probably best to avoid 'make install')
<taylanub>to rebuild, just run: guix environment guix --pure -E make
<toothbrush0>mark_weaver: um, i mean, assuming i'm not going to throw away my Arch installation, but i'm willing to install guix from scratch, how can i prevent that from happening
<mark_weaver>well, I still recommend building guix within git, because it allows you to easily customize it and contribute patches to us.
<toothbrush0>but if libgcrypt is an exception (i'm guessing, given your --with-libgcrypt-prefix.. flag) will i run into this with some other library down the line if i don't do the --with-frooble-prefix=$(guix ...) for it, too?
<taylanub>toothbrush0: after that you might still get "substitute: warning: failed to install locale: Invalid argument" sometimes when using 'guix package' and such, for which I don't know the solution yet because it seems harmless so I didn't bother so far
<toothbrush0>indeed seems harmless, but i don't like warnings. :p
<toothbrush0>hm, so after doing `guix environment guix --pure`, the command `guix` is unavailable -- is this normal?
<mark_weaver>toothbrush0: yes, what you have available is everything needed to build guix from source code.
<toothbrush0>except that above, you suggested i do `./configure ... --..=$(guix ..)`, which doesn't work?
<toothbrush0>or should i have done the `guix build libgcrypt` ahead of time, outside of the env?
<rekado>I do have /etc/sudoers and I haven't played around with permissions anywhere; but sudo isn't working and I also get "permission denied" on execve guile when building packages. So I wonder if that's related.
<oblo>dependencies are a hell.. you think "i don't need it" but you need it
<toothbrush0>davexunit: yeah. i did `guix environment guix --pure` which was rather fast, then at some other point in a fresh shell `guix package -i guix` and now it seems to have done something weird to `guix env guix --pure`
<davexunit>emacs-no-x is a dependency for the guix package, so I could see how some seemingly unneeded dependencies are brought in