<stikonas>nckx: well, it's not really a daemon, it's kauth which is a wrapper around polkit. Basically in polkit world you have a non GUI app which can call small executables running as root when it needs to do some privileged operation
<stikonas>e.g. update some root owned file, change some system configuraion, do something with disk
<nckx>It's *not* official, although it happens to be run by a Guix maintainer. They don't want it to have any special status though. Treat it as any other random untrusted mirror you find on the Internet.
<A[m]2>without this mirror it was not hope to install guix.
<nckx>leoprikler: Not worth sending a mail: after-line comments use a single ; tests don't exist
<A[m]2>I mean minor-modes, not packages, of course.
<A[m]2>electric-pair-mode is what I asked for, will be helpful, I think.
<nckx>A[m]2: Packages made sense too. There are packages like rainbow-delimiters (I think) that are probably helpful to some. Just not me.
<nckx>A[m]2: Once your brackets even out, C-M-q is your greatest friend. 🙂
<atw>qq: I often do things like guix environment --ad-hoc emacs-something -- emacs but of late the launched instance of emacs doesn't seem to recognize that the package is in the environment. Is this related to that EMACSLOADPATH thing? What's the best way around this? I'd be ok with "you should be using a profile"
<atw>anyway, I may have to write an article about this to properly express my feelings, but I think that it's ridiculous that programmers have to do work by by emulating a device from the 60s, whose rich-text and Unicode abilities may be lacking.
<atw>Sorry A[m]2, I'm off-topic. I tried my own advice and it seems to work. Is it possible that the s-expression in front of the point is already indented properly? Is it different if you put the point before the top-level s-exp and then ESC C-q ?
<A[m]2>atw: catern.com - rare site at this times (without https).
<atw>seems like it was in my browser history as http://. Using https:// gets me an expired cert warning. catern, is your certbot running? :P
<atw>aww man gonna have to crank-call my friends and ask them that lol
<mutoshack>Hi, I'm on 0.16.0 and just ran 'guix pull && guix package -u', but I got a "dependencies couldn't be built" error.
<Guixuser44>hello, getting this after running guix pull as a normal user: "Updating channel 'guix' from Git repository at 'https://git.savannah.gnu.org/git/guix.git'... guix pull: error: Git error: failed to connect to git.savannah.gnu.org:Network is unreacable. I know privoxy on proxy-server locally works, as I have tested it with lynx on the same box, plus a
<Guixuser44>nother local machine. So the issue is how to configure this to work. I've set environment variables https_proxy and http_prxy to no avail.
<Guixuser44>DNS works btw, so gnu.org domain responds to ping
<Guixuser44>sorry, does not respond to ping, as direct network is blocked.
<Guixuser44>I meant that the hostname git.savannah.gnu.org resolves correctly to 220.127.116.11
<marusich>mutoshack, that's a bit rough. One possible way you might be able to get to the latest version is to try invoking "guix pull --commit=$some_commit", where $some_commit is a later commit. You would run "guix pull" commands like these to do it: http://paste.debian.net/1119391/
<marusich>So, you could try pulling version 0.2, then 0.3, then 0.4, etc. Or if you're feeling lucky, maybe you could try one in the middle.
<Guixuser44>It works fine from another computer in the network on the same local subnet. So it is not an issue with the local proxy server itself.
<Guixuser44>to clarify: if proxy is 192.168.1.1 and guix is 192.168.1.11 and other box is 192.168.1.10, then the ..10 box works fine with the http and https proxy on ...1, however guix box does not work as i want it to, might be becasue I do not have too much knowledge about guix, but trying to get to know it. I have googled this, but it is hard to figure out.
<Guixuser44> Also, it is very unfamiliar with going away from the standard /etc fiddling to configure services, but I will get used to it.
<marusich>I understand that the 192.168.1.10 host has access, but I'm wondering if the 192.168.1.11 host has access. Determining whether it does, was why I asked about git and curl.
<marusich>When you run "guix pull", it's either going to try to fetch the Git repository in the environment of your user or the guix-daemon; I'm not sure which. It sounds like you arranged to start the guix-daemon in an environment where http_proxy and/or https_proxy are set correctly, right?
<Guixuser44>curl http.com gives expected output, so it has access to the proxy server.
<Guixuser44>-> It sounds like you arranged to start the guix-daemon in an environment where http_proxy and/or https_proxy are set correctly, right? <- I have tried to do this. Is there a way to verify it?
<marusich>Guixuser44, I double checked the code for "guix pull", and it seems like it is fetching the Git repository using libgit2, in the context of your user's environment, rather than asking guix-daemon to fetch the repository on your behalf. Therefore, if you can run "curl -v https://git.savannah.gnu.org/git/guix.git", then "guix pull" ought to be able to reach the Git repository. Could you check that the curl command succeeds from 192.168.1.11?
<marusich>If you've set up your environment to use the proxy when you run commands like wget, curl, nc, git, etc., then it ought to probably work for "guix pull", too. If the curl command I mentioned works but "guix pull" doesn't, then I'm not sure what the problem is, and maybe if you could share more detalied output via paste.debian.org, I could take a look.
<Guixuser44>yes, thanks for checking that, i cam to the same conclusion re libgit2. In fact that curl command does not work, it hangs with ALPN, offering http/1.1. From the other machine it seems to work. Curl version on guix is newer. Hm. gotta reeach the ALPN err
<Guixuser44>so obv something wrong with my setup. tremendously helpful you are btw. much apreciated. Trying to learn these new distros like whonix, guix and qubes. Its quite the adventure
<Guixuser44>ok, one question. I realized it was possible to login to the guix server via ssh with a password. I would like to lock down this to allow only ssh key. So normally i would edit sshd config file, then reload service and all set. In guix i need to edit another file and 'rebuild' the system? Or how does that work?
<marusich>In Guix, the correct way to accomplish that is to change the operating system configuration file, and then run (as root, so you can write the bootloader and update various symlinks that only root has access to): "guix system reconfigure the-config.scm"
<marusich>As for how you modify the operating system configuration file, assuming you are using OpenSSH, you need to modify the configuration used by the service of type openssh-service-type.
<Guixuser44>ok, thanks. so the file to edit will be config.scm in etc? I did edit that file before, admittedly the workstartion guix is running on is not the fastest machine, but it took a very long time to complete. is that intended behavour? As compared to most other linuxes, you just edit sshd config file and restart the service. For instance, if you are ex
<Guixuser44>perimenting a lot with different setitngs in the sshd config file, then this method is not very expedient. However, I guess for such expermenting, a custom file and port should be used. It just seems overkill to rebuild everything for such a small change. But maybe there's a philosophy behind it?
<marusich>After you've run "guix system reconfigure" once, as long as you've only made minor changes like the kind we're talking about here, subsequent runs should complete pretty quickly, like within a minute or two. I realize that isn't as fast as manually modifying configuration files in /etc and then manually restarting a service, but that is the trade-off for describing the entire system declaratively. Guix does its best to make it as fast as it
<marusich>can, but yeah it's still not as fast as I'd prefer. Faster is always more pleasant.
<Guixuser44>ah, okay, i never tried that. the last time i ran it, it took ages ...
<marusich>yeah, if it's the first time, or if you made significant modifications (e.g., pulled in a new package as a dependency), then it's going to take longer.
<marusich>Correct. So, you could also manually install the key outside the scope of Guix.
<marusich>I believe Guix installs the keys to /etc/ssh/authorized_keys.d/
<marusich>And then it starts sshd with an appropriate configuration file that tells sshd to look there for keys, also.
<marusich>BTW, if you're curious to see the actual config file used by sshd, you can find it by running "ps -wwfe | grep sshd" and looking for the -f option. it'll be a file like /gnu/store/fnsb582n2pyrm3gjmsc6idkbav8c036l-sshd_config - note that it is in the store, which means it's immutable. It isn't being read from a place liked /etc
<Guixuser44>So, since security is quite important, not running a millitary op here, but stll interested in keeping stuff secure, how safe is guix, I mean when you update the system, the updates must come from a server, how easy is it for an adversary to compromise the sources? Are there any safeguards in place like multi-signature release? Ie what prevents the
<Guixuser44> admin of the update server from injecting some malicious code into a package? Of course I don't distrust the maintainers, but this is kind of an intellectual question. As ideally I think it would be best if releases are only possible when they are signed by multiple parties on multiple locations, if not, then any powerful entity can threaten a sin
<Guixuser44>gle dev which has the release key to push a malicious release
<Guixuser44>thanks for the tip, i have played with sshd extensively in a non-guix context, but the tip was anyway a good one
<marusich>Those are good questions to ask. I won't try to answer them comprehensively, but I will mention the following. Because Guix follows the purely functional software deployment model, if you have authorized substitutes from a substitute server (e.g., ci.guix.gnu.org), Guix will transparently download substitutes from the substitute server when they are available, otherwise it will download the source from the location specified in the package
<marusich>definition and then build the package locally from source.
<marusich>This feature is called "transparent source/binary" deployment; Nix has it, too.
<marusich>The substitutes are digitally signed with the substitute server's key. Someone with root privileges on the local machine can authorize or de-authorize substitute server keys.
<marusich>Guix verifies the digital signature when downloading substitutes, so even if they come from some random place (like a CDN), you can be sure you are getting the exact same software that was signed by the substitute server.
<marusich>When Guix builds from source, as I said, it downloads the source first and then compiles it. The source comes from whatever URL is specified in the package definition. The package definition contains a content hash (sha256) of the source contents, which ensures it is the same contents as when the person who wrote the package definition checked.
<marusich>The people who write the package definitions are anyone who has commit access to Guix and, if you use any other channels, those channels. For Guix's core channel, all commits are signed, and everyone does their best to verify the sha256 value of a source (e.g., a tarball containing the release of linux-libre), before committing it. Committers are expected to do things like verify GPG signatures, when available, before committing the package
<marusich>The people who have access to the ci.guix.gnu.org infrastructure and privileges allowing them to invoke sudo might, hypothetically, be able to abuse their access to insert malicious substitutes signed by the ci.guix.gnu.org key. The people who have access are decided by the Guix sysadmins.
<marusich>I'm not sure if Guix verifies the Git commit signatures when running 'guix pull', but if any substitutes are used when running 'guix pull', those substitutes' signatures will be verified by Guix as usual.
<marusich>When I looked at the code, it seems that our use of libgit2 doesn't verify the Git commit signatures. But you can fetch the channel over https, which uses TLS, so that's good.
<marusich>I don't know how the security of the Savannah infrastructure is managed, but surely it can't be that bad, since it's used by many important projects.
<Guixuser44>There are some terms in this process I am unfamiliar with, but in short what you are saying is that as users we need to trust single individuals (eg: devs), and if a dev is compromised, then there's no guarantee that malicious code is not propagated? Trusting a signature is ok, but if the one holding the key is compromised, then there is no elabora
<Guixuser44>te safeguards to defend against that? So lets say gov official/LE asks dev/website maintainer to prepare a specifically crafted package (sorry if my terminology is off) for downloads going to a specific ip-address in say Iran, how would that be detected? This could be done to secure shell access on a targets computer. All other users would be serve
<Guixuser44>d the normal files. I guess the target could protect against this by downloading through many different ip's and check for inconsistencies, or to download over tor, so the ip constantly changes.
<marusich>I think the risk of that is similar to the same risk in any project. For example, you could ask the same question about the openssh developers.
<marusich>But assuming that you trust the devs, the sha256 hash of the source in any given package definition ensures that when Guix builds from source, it's building the source that was intended by the developer. And the digital signatures on substitutes ensure that when Guix downloads and uses a substitute, that substitute is exactly the same as what was built on the build farm.
<marusich>If you go all the way down to the bootstrap binaries - the opaque binaries from which everything else is built - those are also protected in a similar way. Their SHA256 hash is recorded in Guix's code, and they are downloaded from a remote server and verified against that SHA256 hash before they are used.
<Guixuser44>I have just alway though that proprietary software is inheritly insecure as there is no way to know what is running, so what prevents nsa from backdooring windows updates going to certain servers inNK for instance. As for open source software, there is the community looking at everything, but if a users is targeted specifically he will see nothing
<Guixuser44>wrong, unless he develop an elaborate defense. Most users trust software signed with a trusted pgp key.
<marusich>Sure. That is true for any project, really.
<Guixuser44>Just looked up the substitute definition. subts are prebuilt items, like deb,rpm in other distros. But
<marusich>Going farther, security updates to Guix are delivered by committing them to the master branch in a way that causes them to be used as "grafts". Normally you would just update the package definition, but if it's a widely used library, like glibc, it would cause tons of rebuilds, which would take a long time. Grafts allow updates to be applied quickly; you can read more about them in the manual. Essentially, if A depends on B and B needs to be
<marusich>upgraded, Guix builds B' and then quickly builds a version of A that is constructed not by building it from source, but by taking the original A and simply updating all the references in all its files from B to B'.
<marusich>Eventually, those grafts are removed when the actual change which causes A to be rebuilt from source using B' is merged to master.
<Guixuser44>I assume there is a pgp key locally on guix install which is used to verify a subst dl? so if the dev making that subst is compromized, the end user is compromized. And if this update is pushed only to a specific user, then the community will not detect it. So, the infrastructure should have IDS systems in place, and procedures to deal with intrus
<Guixuser44>tions / physical threats. Is it a all feasible to require that substitutes that should be made available must be signed by 2/3 devs or 3/5 devs for instance? They could all be spread out geograhically and even be anonymous partly or fully, as long as they've proven over time they can be trusted. The reason anonymous could be good is that it would b
<Guixuser44>e harder to get to all of them. I mean, a powerful org. could easily hold a single dev at gunpoint, but 3 out of 5 devs in different jurisdication would be much harder. I am aware this is going into tinfoil hat territory here for a bit, but I am really interested in the theory behind keeping everything as legit as secure as possible. Therefore I al
<Guixuser44>so use qubes, which is non-monolithic, but again it is not perfect, as intel processors have flaws which can lead to privilege escalation, which is a bit scary to be honest. But for ordinary users, I think it is reasonably secure. Wold adding 2/3 or 3/5 signing lead to too much bureacracy or inconvenience? Is that too much?
<Guixuser44>thanks for the invite. I think participation on the mailing list first is a good alternative, getting to belgium would be a significant journey. recently I found otpclient, which can be used offline, and is a better alternative than authy and google authenticator on a phone imo, not sure if this is included in guix, if it isn't, how extensive is it
<Guixuser44> to contribute to have it included as a substitute? There are so many new concepts for me with guix as it is fifferent from debian which i have used mostly.
<Guixuser44>ie i think it is better to run otpclient on a 100% offline device, as phones are insecure by design, and also i dislike cloud solutions for 2fa
<Guixuser44>thank you very much for all the detailed info, and your very friendly attitude. I certainly have a lot to read and learn.
<marusich>To cap off the discussion of the signing key, looks like it's a public/private keypair. The security of the key will depend on the parameters used, the quality of the implementation in libgcrypt, and perhaps the system on which you run it (e.g., probably good if you have lots of entropy?).
<davie`>its included in packages already. Its super cool. You can use it in cmd
<marusich>I don't know much about otpclient. When I ran "guix package --search=otpclient" and "guix package '--search=otp.*client'", I got no results. So maybe it isn't packaged. Sounds like maybe davie` has an alternative you can use!
<marusich>As for the Guix Days, sure, maybe next time. It's a lot to take in, and starting by watching the email lists is good. And by chatting on IRC! It's a great community.
<davie`>no its called oath-toolkit its a lib with command-line interface you can use for otp 2fa
<marusich>FWIW, I feel just as comfortable using Guix as another distro for my own personal computing. However, it's true that Guix's community is smaller, so the coverage in terms of eyes and people-power is lower. Updates are fast for some packages that people care about, and slow for others. No security audit has been performed to my knowledge, which puts Guix in the a similar situation as many projects.
<davie`>marusich: regarding package updates... I've been packaging some python and go packages and found out that many of those that are already present in guix repo are outdated. What I thought of is following... We don't have package maintainers and we won't have. I't kind of guix way. But we can have a tool for coverage which packages are up-to-date
<davie`>So we can keep up with pipy or github or gems oo hackage or etc.
<marusich>There are potentially interesting ways to use the Guix Data Service that Christopher Baines has been working on, in order to query all the packages and do various things with them. I'm sure with a bit of work, the GDS could be used to generate, e.g. a web page showing the status of packages. How out of date they are, what CVEs are out, etc.
<marusich>I'm not deep into those things, but they're really cool. Look into it if that's up your alley
<marusich>The command "guix refresh" is supposed to help update many packages, which might help with what you're saying.
<marusich>"guix lint" has a CVE checker which attempts to identify packages with known CVEs.
<marusich>One other area we are lacking is in something similar to a Nessus scan; it would be nice to surface vulnerabilities to users if they are using a terribly out of date profile, for example.
<jyscao_>instead of using either git-fetch or url-fetch to retrieve the package source, is it possible to directly specify a path on my local fs? I ask because I've made some changes to the package's build steps, and would just like to test it out
<pat_h>Hello everyone, does anybody have an idea about the simplest way I can go about invoking the 'configure' step for a package with bash in xtrace mode? When I add a pre-configure step to invoke "set -xv" the process halts with error 127 (command not found), and this doesn't seem possible to do via setting environment variables either.
<leoprikler>pat_h: perhaps you'd like to `guix build -K`, then abort and inspect /tmp/guix-build-...
<mbakke>pat_h: you probably have to (substitute* ...) the script in question to add the "set -xv" line
<pat_h>mbakke: Not sure why I didn't think of that ha, I'll give it a shot
<pat_h>nckx: I'm a little squeamish about doing that but as a last resort that sounds good, thank you!
<nckx>pat_h: Why? It's equivalent to patching and less intrusive. But the effect is the same, do whatever feels best. You can add an (invoke "balk"), or any other invalid command, to abort the build so you can inspect it with --keep-failed.
<nckx>If so, you can add it as a special-file in your system.scm, but chances are it will fail to load any shared libraries. You can use patchelf to modify the binary to use /gnu/store libraries instead.
<nckx>kirisime: What are Appimages? Are they statically linked?
<kirisime>nckx: They're supposed to be self-contained binaries for distro-agnostic application delivery.
<leoprikler>(tbh. I'm glad emacs-telega got added, so I no longer have to keep flatpak around, yay)
<erudition>(I'd love for pithos to be added for the same reason!)
<kirisime>Speaking of which the first reason I tried to run appimages is that Guix' package for krita has some bug that causes it to crash when I create a canvas with GPU acceleration on when running on my discrete AMD GPU. Doesn't happen on the flatpak version.
<lfam>Hm, could you send a bug report to <firstname.lastname@example.org>?