<NiAsterisk> re: bug on guix-bugs... sorry, I should write an email tomorrow on how I solved it and why sending to bug list was stupid in the first place. prior to this system I did not work with (local) branches in guix i worked on the master (i think), now that I work with branches which track the master it failed when I was checkout on the branch, but succeeded with master checkout
<NiAsterisk>how do you do it, developing locally? branching? just working on the origin/ branches?
<NiAsterisk>clearly I did something stupid with the way I used branches, but it used to work some time ago
<NiAsterisk>anyhow, gotta go. maybe I ask tomorrow again about this. problem is kinda fixed now.
<cehteh>there are way too much things still which raise the entry barrier, i caught by that to
<cehteh>anyone who uses guix or works with it since some longer prolly doesnt even notice that
<myglc2>Of course the next thing I want is to run emacs in a X window. I assume I need to add the equivalent of the 'services.openssh.forwardX11 = true;' and 'programs.ssh.setXAuthLocation = true;' that I had to add to the NixOS example config, right?
<lfam>I think it's good to start a fresh system with ssh on a non-standard port if root's password is empty
<myglc2>It looks like my guixSD install came up denying root login on ssh, isn't this good enough?
<myglc2>... and so I set the root login in a console terminal, which seemed OK to me.
<lfam>Perhaps. It depends IMO on how the rest of the privilege escalation system is configured (sudo, user passwords, etc). I personally think it would be best if new users tested their OS declarations in QEMU before using real hardware, especially considering how easy that is.
<lfam>If users are blindly copying and pasting the examples then I think it's best to obscure the port
<lfam>Because that means they don't even know whether or not root logins are disabled
<myglc2>Maybe I'm weird, but I have a server on my local LAN and my sniff test is to install on a real machine since that is how I intend to use guixSD.
<lfam>It would have taken me a long time to get a working OS declaration by iterating on real hardware. But I'm no Scheme expert ;)
<myglc2>For my part, I always hope that "blindly copying and pasting the examples" will get my machine up and running in a vanilla way, since there is already enougn confusing new stuff to learn.
<lfam>You're lucky that (file-systems) worked for you with /dev/sdX and a partition named 'my-root' ;)
<lfam>Anyways, since the desktop services include NTP, new systems are going to be getting port scanned by shodan within minutes of coming up. So I think that 2222 is okay as a default.
<lfam>Also the default lsh-service uses 22. It's only people that copy and paste that get 2222
<myglc2>Oh, I fixed sdX & my-root which were obvious... even to me. And don't get me wrong, I'm not complaining, just suggesting. My guixSD install actuallyreally went well.
<lfam>I do think we should streamline it as much as possible but this is one bump in the road that I think makes sense. I got hung up on 'my-root' ;)
<myglc2>If you want the bare-bone example config to include an example of passing in an config argument, how about the ones necessary to enable X11?
<myglc2>FWIW, I have been coding for more years than I care to admit, and I always copy and try first, and then try to figure out what went wrong later...
<lfam>Did I want that? That could be a nice addition to the installation guide
<lfam>My approach is to try to understand it as much as possible for a neophyte, and then copy and paste. But I like to understand each step as much as I can. Sometimes that's not very much understanding, though...
<lfam>Ugh, I hate seeing 'patch-patches' in a package definition. That's when you know you're in for a rough ride.
<myglc2>I think it is cool that there is an example of passing a config argument into lsh-service, since it is highly likely that one will want to be doing so immediately. I just think maybe the value shoule be 22 instead of 2222, and xauth and X11 should also be there.
<lfam>Then I think we should use the mailing list to review the change in light of the rest of the security defaults, as I mentioned a few minutes ago.
<lfam>Not that using a non-standard port is really a strong security stance, but it is something.
<mark_weaver>but I'm sure we won't want to add X to the "bare bones" config.
<lfam>mark_weaver: icedtea is a bumpy road as well
<mark_weaver>I think the idea is bare-bones really means what it says, and if you want those things you should add them.
<myglc2>mark_weaver: OK Thanks I'll raise it on the user list.
<lfam>mark_weaver: I started with icedtea-1 (based on openjdk-6) since icedtea-2 (openjdk-7) inherits from it. However, one of the many upstream patches does not apply to the relevant file! And I can see that related patches will not apply either.
<lfam>The patch "patches/openjdk/p11cipher-6682411-fix_indexoutofboundsexception.patch" wants to alter the string 'public int unpad(byte paddedData, int ofs, int len)', but that string only exists in the source tree in that patch. So I'm going to report the bug upstream and put this on ice.
<lfam>In that case, I'm not sure who would do it on our end...
<mark_weaver>lfam: has debian or fedora addressed this problem yet?
<mark_weaver>was are the CVE numbers? how did you find out about it?
<lfam>I learned about it from DSA-3458-1. The CVEs are: CVE-2015-7575 CVE-2016-0402 CVE-2016-0448 CVE-2016-0466 CVE-2016-0483 CVE-2016-0494
<lfam>sneek: later tell mark_weaver: The DSA message didn't address the icedtea built on openjdk-6. But they did update to the newest icedtea release. So perhaps I should try to decouple our icedtea packages and try building the one based on openjdk-7.
<sneek>mark_weaver, lfam says: The DSA message didn't address the icedtea built on openjdk-6. But they did update to the newest icedtea release. So perhaps I should try to decouple our icedtea packages and try building the one based on openjdk-7.
<lfam>Actually, I can still build the openjdk-7 version. Inheritance doesn't require the "parent" to build
<mark_weaver>ah, good. so is there a problem? do we have patches that don't apply cleanly?
<mark_weaver>it sounds like we can simply update to 2.6.4 and 1.13.10
<lfam>Not our patches. Upstream includes a huge amount of patches that are applied to the bundled openjdk source code. Those are the patches that I am having trouble with. Looks like there is a similar problem with icedtea-2 based on openjdk-7 (the one in the DSA)
<NiAsterisk>something else... libreboot with both of my laptops is testing ground (displays not even in the tested/untested category), but coreboot seems to have no issues.. will having coreboot spare me the hassle to hack the lenovo bios and whitelist the no-blob wifi cards I bought
<NiAsterisk>the names people come up with for libs and software... "viagra"... mkay.
<myglc2>In bare-bones.scm I changed '(packages (cons tcpdump %base-packages))' to '(packages (cons emacs %base-packages))' and now 'guix system build /etc/config.scm' gives me root@g1 /etc# guix system build /etc/config.scm
<myglc2>guix system: error: failed to load '/etc/config.scm':
<myglc2>/etc/config.scm:8:0: In procedure #<procedure 37fd520 ()>:
<myglc2>/etc/config.scm:8:0: In procedure module-lookup: Unbound variable: emacs
<myglc2>OK, thanks. I did a guixSD install but not yet really understanding exactly what that gives me or how best to use it or what to do next (but not a complaint, OK)
<GChriss>is there a quick crash-course for scheme syntax linked to from guix doc pages somewhere? just ordered a copy of "Structure and Interpretation of Computer Programs" but wanted to know if there was a 15-min condensed version as it's typically used in guix scheme files
<mark_weaver>I guess his /boot is on the encrypted root partition, and grub realizes that it won't be able to load its modules. but on a libreboot machine, it doesn't matter because libreboot has its own grub burned into the boot flash.
<mark_weaver>so on libreboot, we don't actually need to install grub, we only need to install grub.cfg which can be loaded by libreboot's grub.
<myglc2>Ooo, I'd like to have a machine like that.
<CompanionCube>is there a verbose mode for guix-daemon? just curious/wondering
<NiAsterisk>hm. would it be better to reach out to torproject to ask them to do the packaging of tor browser bundle in an appropriate form for guix or torbrowser, or something involving the browser, than to maintain it by people here?
<NiAsterisk>it's on my list.. but I thought torporject, maybe it would be in their interest, or someones
<civodul>NiAsterisk: i actually asked a Tor developer in December and it seems not easy
<mark_weaver>Hydra has finished building the new security-patched icecat. make sure to update it asap, everyone!
<CompanionCube>FF 44 unfortunately has a visual break for me that was enough to downgrade
<NiAsterisk>I have some short term motivation for primary guix focus for myself, which does not involve tor primarily, but torbrowser would be a nice feature add. I want to be able to produce a laptop server, and variations of the original, with psyed+httpd+git-daemon on tor hiddenservices + gnunet and gnunet services + iptables and some more, as the basis. and then variations of pure tor etc.. it makes me sad that it will
<NiAsterisk>take some time, but I'll probably learn much about service constructions and useful things.
<NiAsterisk>being able to deploy and control it all from one file for guixsd (and including additions for just guix on host systems for example for psyced).
<civodul>mark_weaver: great, thanks for the heads-up