<civodul>and the problem is that we need to diverge now <mark_weaver>yeah, and we'd have to update the guix-daemons on all of our build farm slaves. <civodul>well, technically we could do some fancy stuff with git to do that <civodul>we still need to take the good stuff that happens here and there in Nix ;-) <civodul>so instead of using a submodule, we need to switch to filter-branch + read-tree, something like that <davexunit>I didn't realize we were at the point of diverging from the nix daemon. <davexunit>are the long term plans to replace the daemon with a guile implementation? <mark_weaver>or we could still the same submodule stuff, but use our own git repo that periodically merges from the upstream one. <mark_weaver>civodul: do you know of a change that you'd like to make that nix won't accept upstream? <civodul>mark_weaver: no, it's generally accepted <civodul>it's always accepted even, in practice <civodul>actually we can't wait, because we can no longer update our submodule <civodul>they some minor thing about command-line parsing <civodul>and there are many details that would be better handled in a branch <civodul>rather than calling sed from sync-with-upstream ;-) <mark_weaver>so let's just clone their repo, make the branch in our repo, and periodically pull from them. <civodul>but we need a bit of filter-branch, to keep only what we need <civodul>i'm not exactly sure how to do it technically <civodul>if you or someone else wants to give it a try, i'm happy with it :-) <mark_weaver>I'm a bit overloaded at present, and my git knowledge is rather limited. maybe post to guile-devel about it? <davexunit>civodul: you want to use filter-branch to scrap everything that isn't the daemon, yes? <oiuoiu>mark_weaver: I'm on i686. Guile fails to build. guix-register was mentioned to clarify that my setup had been (almost) correctly installed <oiuoiu>in particular, guile fails after GUILEC ice-9/boot-9.go <oiuoiu>civodul: hello, I clarified some things yesterday when you weren't present on the channel. *civodul looks at the log <civodul>ok, could you post the tail of the build log? <civodul>could it be that the machine is very slow? <civodul>because it does take some time to build the early .scm files <oiuoiu>It is slow by today standards, but I've successfully used Guix on it. <civodul>yeah; 1h to build that would be very suspicious <civodul>if you built with -K, could you go to /tmp/nix-build*, source environment-variables, and run 'make' again? <oiuoiu>is there a quick way to restore the initial env after that? <civodul>yes: go to that directory, and type "source environment-variables" <mark_weaver>civodul: I think we should probably merge bash-cve-2014-6271, even though there are other bash CVEs. it's still an improvement, and it's fully built on intel platforms. wdyt? <mark_weaver>I'm not sure whether to wait for more official patches from Chet or not. <civodul>and we can start building the rest afterwards <civodul>(i'll work on the grafts during the hackathon, i think) <civodul>oiuoiu: oh, you need to run "chown -R $USER /tmp/nix-build*" <mark_weaver>my feeling is that we should create another branch with at least the eol-pushback and parse-oob patches applied, and start hydra building it <mark_weaver>I'm undecided on the variables-affix parse. applying it would be safer for security but might conceivably break something, and it might not be adopted as-is, so we might need to revise it later. thoughts? <civodul>mark_weaver: could you send this as an update to the ML? <mark_weaver>I need to sleep soon, so the ML update will have to wait a bit. <mark_weaver>in fact, I should really go to sleep right now. so late. <civodul>hmm, the FSF writes: "Development of Bash, and GNU in general, is almost exclusively a volunteer effort" <civodul>i would s/almost exclusively/in part/ <mark_weaver>I think the CVE for eol-pushback might be CVE-2014-7129, but I'm not sure. <civodul>mark_weaver: yes, that was the second one <civodul>but it's unclear whether the patch was actually blessed <mark_weaver>It might be good to start hydra building a branch with the eol-pushback and parse-oob patches applied. *civodul prepares the branch <oiuoiu>civodul: I think make succeeded. What does it mean? <oiuoiu>civodul: nope, I should have run it via time. *davexunit thinks about proposing a guix talk for libreplanet 2015 <davexunit>this year's theme is "free software everywhere", which I think fits right in with what guix is trying to do. <philed>Dumn question time. Is the idea for GNU services to all be configured using scheme, scrapping the usual key/value pair configuration files everyone else uses? <philed>So if someone wants a service which relies on such a configuration file, is it generated on demand and then removed on shutdown or something? <davexunit>well, the service definitions are written in scheme, but the programs that the service runs are configured in whichever way the program does it. <davexunit>an apache2 service would still use regular apache config files. sorry for any confusion. <philed>Ah, okay. So I'm still editing those regular files to configure apache2? <davexunit>yes. I haven't actually played with the init system very much yet. <davexunit>in guix, we want operating system configuration to be reproducible, so those configs would need to be reproducible as well. <davexunit>but I'm past the end of my knowledge about how that works. <philed>I thought that might be the case. So I was wondering whether the configs are supposed to be generated by the init system from scheme? <davexunit>someone else will have to answer that. I don't know. <davexunit>I think this is more of a guix question than a dmd question. <philed>Looking at the xserver.nix code for NixOS, and it is pretty clear that xorg.conf is being generated from a template. So I guess it's supposed to be the same for guix. <civodul>davexunit: re Libreplanet, go ahead! :-) <davexunit>I will probably have to do a session anyway, might as well try to make it about a topic of my choosing <davexunit>oh cool, I never read the source to the xorg service before <civodul>davexunit: BTW i'll probably have to fix the implicit input issue to implement "grafts" <civodul>i'm thinking of adding a "method" to build systems that would lower a package with implicit inputs to a package all-included <davexunit>is that the term for the feature that enables quicker security fixes? <davexunit>that sounds like a good idea for the build systems. <civodul>i'll be happy to get your feedback on this <davexunit>I'm itching to have a working 'guix environment' <davexunit>having GUIX_PACKAGE_PATH will benefit 'guix environment', since now I can always use the package search facility instead of reading directly from a file. <davexunit>for convenience, I wonder if guix environment should implicitly add $PWD to the load path <nully>does nayone know whats up with CVE-2014-7169 ? <mark_weaver>hi nully, I was looking closely at the bash problems up to about 4am Eastern Time. just woke up. <nully>mark_weaver: i'm comaparing the deebian patches to whats in the bash ftp archive <nully>the debian fix for 7169 is 1 line... <nully>does not see to be in the latest fix patch on the ftp site <nully>(two lines if you count ht enew line <mark_weaver>this is the eol-pushback.patch ? (adds eol_ungetc_lookahead = 0) ? <mark_weaver>nully: there haven't been any official bash patches since the original bash CVE, which is not sufficient. <nully>mark_weaver: i kinow.. i'm troubled <nully>debian applied it themselves <mark_weaver>as of 4am, I saw two other patches that should almost certainly be applied, and one that's more radical and not fully compatible, but maybe still a good idea. <nully>the nasty ldpreload hack t hey do on the server side? <nully>what patches have you applkied in GUIX? <nully>and mind you have to make this work on 3.1, 3.2, 4.1, and 4.2 <mark_weaver>so far, we've only applied the one that debian applied, but I suggested that we immediately apply eol-pushback and parse-oob <mark_weaver>I suggested that we hold off on variables-affix for now, at least in official guix. <nully>mark_weaver: debian applied 2 patches <mark_weaver>nully: the message I referenced also included variants of the parse-oob and variables-affix patches for bash 3 <nully>the eol-pushback one was pushed out by debian around 3am <nully>i pulled it, compared it to the FTP archive, and Trisquel <mark_weaver>nully: oh, sorry, I meant the earlier debian update. <nully>mark_weaver: debian put the eol-pushback patch into stable <nully>so i think its safe to say they feel good about it <nully>i'm going to package it now and roll it out <mark_weaver>the parse-oob patch also seems like a no-brainer to me, personally. <mark_weaver>I suspect the only reason it's not in debian yet is that it came out later. <nully>- if (word_top < MAX_CASE_NEST) <nully>+ if (word_top + 1 < MAX_CASE_NEST) <nully>^--- that part i'd wanna dig into be fore applying <nully>that feels sloppy for some rason. <mark_weaver>well, admittedly I'm trusting that the folks on the redhat security team and others on oss-security did the right thing on that off-by-one bug. <nully>i might wait for bash upstream to patch that one <nully>if i have time i will look into it, debian hasn't applied it yet either. <nully>(they have closed both CVEs) <mark_weaver>well, at this point I've seen at least 5 CVEs associated with this bash thing, although I think some of them are ill-defined and maybe overlap. <nully>reading the list a bit more... <nully>ya, you are right, its one of the overlappers <mark_weaver>but there are two CVEs for the bugs fixed by parse-oob <mark_weaver>so I guess you've decided to fix one of them and hold off on the other one? <nully>i'm going to chat w/ some friends <nully>and see what they say, while ipakage the first fix <nully>ya, 7186, then 7187 and hten i'm going to go to sleep :D ***jgay is now known as jkay
***jkay is now known as jgay
<civodul>mark_weaver: just created bash-cve-next <civodul>(i was unable to finish it during work hours)