IRC channel logs

2014-09-26.log

back to list of logs

<civodul>yes
<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.
<davexunit>civodul: time to fork from nix?
<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
<civodul>but it's beyond my git foo
<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?
<civodul>of course :-)
<civodul>but that's long term
<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>*still keep
<civodul>yeah dunno
<davexunit>I like that idea.
<mark_weaver>civodul: do you know of a change that you'd like to make that nix won't accept upstream?
<mark_weaver>they might accept the ip6-localhost entry
<civodul>mark_weaver: no, it's generally accepted
<civodul>it's always accepted even, in practice
<mark_weaver>okay, so we can wait a while
<civodul>actually we can't wait, because we can no longer update our submodule
<civodul>they some minor thing about command-line parsing
<civodul>but that breaks our stuff
<civodul>so we need our own branch
<mark_weaver>oh
<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.
<mark_weaver>IMO anyway :)
<civodul>yes, definitely
<civodul>but we need a bit of filter-branch, to keep only what we need
<civodul>things like that
<mark_weaver>ah
<civodul>i'm not exactly sure how to do it technically
<civodul>which is why i haven't done it yet
<mark_weaver>okay
<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?
<civodul>davexunit: exactly, yes
<civodul> https://www.kernel.org/pub/software/scm/git/docs/howto/using-merge-subtree.html <- i think this is what's needed
*civodul -> zZz
<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
<civodul>Hello Guix!
<oiuoiu>civodul: hello, I clarified some things yesterday when you weren't present on the channel.
<civodul>oh, ok
*civodul looks at the log
<civodul>so it's on i686, from Guix master?
<oiuoiu>yes
<civodul>ok, could you post the tail of the build log?
<oiuoiu>how long?
<oiuoiu>how many lines, I mean?
<civodul>50 or so
<civodul>to get an idea
<oiuoiu>okay
<oiuoiu>civodul: http://dpaste.com/0NKADD3.txt
<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?
<civodul>to see if it completes
<oiuoiu>is there a quick way to restore the initial env after that?
<oiuoiu>dump to a file and source it?
<civodul>yes: go to that directory, and type "source environment-variables"
<oiuoiu>civodul: http://dpaste.com/3731WG6.txt
<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>the other three patches I'm aware of are: http://seclists.org/oss-sec/2014/q3/att-690/eol-pushback.patch (from Chet), http://seclists.org/oss-sec/2014/q3/att-712/parse-oob-4_2.patch (seems non-controversial), and http://seclists.org/oss-sec/2014/q3/att-712/variables-affix-4_2.patch (more radical hardening, not fully compatible, but maybe still a good idea)
<mark_weaver>I'm not sure whether to wait for more official patches from Chet or not.
<civodul>mark_weaver: yes, ok for the merge
<civodul>
<civodul>
<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>FYI, this following message assigns two CVEs (CVE-2014-7186 and CVE-2014-7187) to the two flaws fixed by the parse-oob patch: http://seclists.org/oss-sec/2014/q3/735
<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?
<oiuoiu>separate branch?
<civodul>mark_weaver: could you send this as an update to the ML?
<civodul>so many CVEs to keep track of ;-)
<mark_weaver>I need to sleep soon, so the ML update will have to wait a bit.
<civodul>branch merged
<mark_weaver>thanks!
<civodul>ok, np
<mark_weaver>in fact, I should really go to sleep right now. so late.
<civodul>yup :-)
<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>think toolchain et al.
<civodul>mark_weaver: yes, that was the second one
<civodul>but it's unclear whether the patch was actually blessed
<mark_weaver>FYI, here's the message that includes the parse-oob and variables-affix patches: http://seclists.org/oss-sec/2014/q3/712
<mark_weaver>It might be good to start hydra building a branch with the eol-pushback and parse-oob patches applied.
<mark_weaver>anyway, time to sleep...
*mark_weaver --> zzz
<mark_weaver>eol-pushback was written by Chet, fwiw.
<civodul>yes
*civodul prepares the branch
<oiuoiu>civodul: I think make succeeded. What does it mean?
<civodul>do you know how long it took?
<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>*Dumb*
<davexunit>philed: yes
<philed>Awesome.
<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! :-)
<civodul>philed: the equivalent for Guix is http://git.savannah.gnu.org/cgit/guix.git/tree/gnu/services/xorg.scm
<davexunit>I will probably have to do a session anyway, might as well try to make it about a topic of my choosing
<civodul>that'd be cool
<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
<civodul>something like that
<davexunit>is that the term for the feature that enables quicker security fixes?
<civodul>yes
<civodul>from the marketing dept ;-)
<davexunit>that sounds like a good idea for the build systems.
<civodul>cool
<civodul>i'll be happy to get your feedback on this
<davexunit>I'm itching to have a working 'guix environment'
<civodul>yeah
<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) ?
<nully>ah
<nully>yes
<nully>that one
<nully> http://ftp.gnu.org/pub/gnu/bash/bash-4.2-patches/ <--- dont see it there
<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
<nully>(the eol-pushback)
<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 redhat fix?
<nully>the nasty ldpreload hack t hey do on the server side?
<mark_weaver>the other one that was not by Chet (bash maintainer) but still almost certainly safe and good is parse-oob-4_2.patch, posted here: http://seclists.org/oss-sec/2014/q3/712
<nully>ya i'm on that list v.v
<mark_weaver>this one, included in the same message, probably helps security but might break something else, and might not be accepted upstream as is: http://seclists.org/oss-sec/2014/q3/att-712/variables-affix-4_2.patch
<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>last night
<nully>(my time)
<nully>i pulled it, compared it to the FTP archive, and Trisquel
<mark_weaver>nully: oh, sorry, I meant the earlier debian update.
<nully>ah
<mark_weaver>(the one from a day or so ago)
<nully>mark_weaver: debian put the eol-pushback patch into stable
<nully>so i think its safe to say they feel good about it
<mark_weaver>yes
<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>the rest seems no brainer
<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)
<nully>although
<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
<nully>ugg ya, i'm in CVE hell
<mark_weaver>FYI, this following message assigns two CVEs (CVE-2014-7186 and CVE-2014-7187) to the two flaws fixed by the parse-oob patch: http://seclists.org/oss-sec/2014/q3/735
<mark_weaver>so I guess you've decided to fix one of them and hold off on the other one?
<nully>still debating
<nully>i'm going to chat w/ some friends
<nully>and see what they say, while ipakage the first fix
<mark_weaver>okay, thanks for the conversation!
<nully>ya, 7186, then 7187 and hten i'm going to go to sleep :D
<davexunit> http://seclists.org/oss-sec/2014/q3/741
<nully>davexunit: http://seclists.org/oss-sec/2014/q3/712 check that one out
<nully>there is a 5th patch too...
***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)