lewo` has quit [(Remote host closed the connection)]
<gchristensen> ok so now we definitely need to solve the nix-on-HS bug somehow, without Apple
mbrgm has quit [(Ping timeout: 260 seconds)]
mbrgm has joined joined #nixos-dev
disasm has joined joined #nixos-dev
<disasm> gchristensen: did you see this reply? http://www.openwall.com/lists/oss-security/2017/10/12/2 related to that high sierra issue? Sounds like NixOS could become a CNA if we're interested.
phreedom has quit [(Quit: No Ping reply in 180 seconds.)]
phreedom has joined joined #nixos-dev
JosW has joined joined #nixos-dev
phreedom has quit [(Remote host closed the connection)]
zraexy has quit [(Quit: Leaving.)]
zraexy has joined joined #nixos-dev
zraexy has quit [(Ping timeout: 246 seconds)]
MichaelRaskin has quit [(Quit: MichaelRaskin)]
<Mic92> disasm: what I wonder if the same works on iOS.
* peti points out that "Haskell eXchange 2017" in London has a 2 hour workshop about Haskell development with Nix this year.
goibhniu has joined joined #nixos-dev
phreedom has joined joined #nixos-dev
goibhniu has quit [(Ping timeout: 258 seconds)]
goibhniu has joined joined #nixos-dev
MoreTea has joined joined #nixos-dev
<gchristensen> Mic92: I assume so
<gchristensen> disasm: I replied right away when I saw that :)
__Sander__ has joined joined #nixos-dev
<zimbatm> are you going peti?
<peti> zimbatm: I'm here right now.
<zimbatm> it's a shame I'm missing it, so many good people are going
<zimbatm> got any plans for tonight?
<peti> zimbatm: There is a reception for attendees with drinks and socializing, so I reckon that's what I'll do.
<zimbatm> ack, see you at nixcon then if you're coming
<peti> zimbatm: Yes, we'll meet there. I wouldn't miss that! :-)
<zimbatm> awesome :)
<zimbatm> enjoy!
<copumpkin> what's the easiest "set all timestamps in folder to 1" invocation?
<peti> zimbatm: Thanks!
<copumpkin> niksnut: I might have an annoying request for you
<zimbatm> copumpkin: something like `find -exec touch –t 1 {} ;` ?
<copumpkin> that was simple :) thanks
<zimbatm> it's not tested, I think there is more to it
<zimbatm> looks like the -t argument take YYMMDDhhmmss
<copumpkin> apparently touch --date=@1403970787 file
* copumpkin tries
<copumpkin> obviously with @1
<grahamc> “supporting multi-user
<grahamc> builds in the Nix daemon” I’d love to rename it from multi-user to something that demonstrates its real value.
<zimbatm> copumpkin: does it work for you? my filesystem or touch seem to ignore it
<copumpkin> still running on large folder
<copumpkin> will tell you soon :)
<copumpkin> I should've tested on a single file
* copumpkin shrugs
<copumpkin> yeah didn't fix it
<copumpkin> I think it's the mtime vs. other time?
<copumpkin> all my files are now modified today
<grahamc> I feel “multi-user” is missing the forest for the trees (despite the whole single user -> tree, multi-user -> forest thing)
<copumpkin> zimbatm: touch -a -m -d @1 sets two of the three dates
<gchristensen> you want to set ctime?
<copumpkin> that last "change" date never seems to change and I can't find an obvious touch flag for it
<copumpkin> yeah
<gchristensen> mtime is modified/changee, ctime is created
<copumpkin> ctime lists as change
<gchristensen> hrm
<copumpkin> but actually that might not be essential
<copumpkin> it looks like nix only cares about the other two
<gchristensen> I thought Nix didn't care about any of them?
<copumpkin> apparently it does, and am 90% sure it breaks image creation in https://github.com/NixOS/nixpkgs/issues/28768
<copumpkin> just testing a bit more though
<copumpkin> niksnut: the idea of calling it privilege escalation is that the logs actually show (although the link in shlevy's email broke) <unprivileged process> killed <privileged process>
<gchristensen> when things get in to the store they're changed to 1: https://gist.github.com/grahamc/c1293b87883e2d979f05efa4fa73c106
<copumpkin> gchristensen: yeah I know
<copumpkin> but I'm not putting things into the store in a conventional way
<copumpkin> for image building
<gchristensen> how else can you get things in to the store?
<copumpkin> well, it's the store inside an image, so it's using cptofs and LKL
<gchristensen> oh I see, ouch
<copumpkin> yup
<niksnut> copumpkin: sure, but it doesn't allow you to do anything more than bring down the system (a DoS)
<niksnut> which on macOS you can do anyway by hitting the power button
<copumpkin> niksnut: well, our point was that since we can't explain why an unprivileged process could signal a privileged one yet, the vulnerability might well be exposed in more targeted ways
<gchristensen> niksnut: an unprivileged process inside a sandbox can do it
<copumpkin> we just happened to find it in kill(-1, ...)
<copumpkin> niksnut: in more annoying news, are you in the mood to generate new 17.09 AMIs? :) :) :) the current ones are very slightly (but annoyingly) broken and it's my fault :(
<niksnut> sure
<niksnut> what's broken?
<copumpkin> the timestamps on some store files, which can break further image creation. I'll fix master and backport to 17.09 and let you know when that's done
<copumpkin> so basically the new image builder is fine
<copumpkin> but running the new image builder inside images built by itself breaks
<copumpkin> I didn't realize it was the latter combo which is why I had trouble reproing https://github.com/NixOS/nixpkgs/issues/28768
<copumpkin> niksnut: on a slightly related note (not for 17.09), do you feel strongly about grub vs. extlinux on EC2?
<peti> domenkozar: Can you please push the new docker image for Nix to docker hub? Or, alternatively, can we please have an automatic build of that file? docker hub supports that kind of thing, no?
<niksnut> extlinux? :o
<niksnut> does that still exist?
<copumpkin> seems to :P
<niksnut> why not lilo? :p
<gchristensen> lilo++
<copumpkin> lol
<copumpkin> my motivations are shady, I admit
<copumpkin> sys/extlinux doesn't need a VM to install itself :P
<niksnut> I think we're better of with as few boot loaders as possible
<gchristensen> I think it would be a mistake to not try and find a way to support multi-user on darwin
<gchristensen> man, so many discussions :P
<copumpkin> so it would let me kill the last remaining VM in the image builder
<copumpkin> anyway I won't change anything yet, but it still seems to both exist and be supported by nixos
<copumpkin> gchristensen: yeah, shlevy and I were noodling about ways to kill all user processes safely on macos
<copumpkin> they were doable but kind of annoying
<domenkozar> peti: I thought I did already? Or were there some further changes?
<niksnut> maybe apple will do something if this hits the HN frontpage: https://news.ycombinator.com/item?id=15456452
* gchristensen unblocks HN to upvote it
<niksnut> hehe
phreedom has quit [(Remote host closed the connection)]
<zimbatm> grahamc: is there any value for "multi-user" aside from the sandbox?
<zimbatm> maybe a better name is "service" or "system" installation
<gchristensen> or "actually reproducible" or "the one where pip won't break your nix install"
<zimbatm> the /nix/store is writeable in a single-user install?
<gchristensen> yeah
<zimbatm> !!!
<gchristensen> that's what I'm saying! :o
<gchristensen> I don't use nix-daemon on NixOS b/c I have multiple users
<gchristensen> I use it b/c it works and the other way lies to you
<gchristensen> it is why I worked so hard on the multi-user install for darwin, so I could recommend my coworkers use it. it being broken on HS is a deal-breaker obviously, but if we can't fix the multi-user part I won't be able to recommend it anymore
<zimbatm> HS == new release?
<zimbatm> new darwin release?
<gchristensen> yeah, High Sierra
<zimbatm> so we should rename the "single user" to "toy" or "shabby"
<zimbatm> and "multi-user" to "proper" :)
<gchristensen> IMO yes, something like that
<zimbatm> single-user is for users that want to test nix
<domenkozar> we could do that once our mainly used installer doesn't use single user
<zimbatm> the nice thing about it is that you can tell users that they just have to rm -rf /nix; rm -rf .nix-*` and remove the .bashrc reference and it's gone
<gchristensen> well ideally we'd rename single-user / multi-user to something that describes them better
<zimbatm> is there any opportunity for doing the change as part of the nix 1.12 release?
<gchristensen> zimbatm: the nice thing about haskell I hear is if you put `-- effectful` and `-- no-referenttial-integrity` at the top of your file you can use IO wherever you want, and have functions return different things with the same parameters
<zimbatm> do you mean it's nice to be able to be impure from time to time?
<zimbatm> but it has to be explicit
<gchristensen> no, I'm lying. I mean to get the benefits you have to do the work
<gchristensen> the easy uninstall, I think, is a red herring
<zimbatm> it could be solved by providing an uninstall script
<gchristensen> yeah :)
<zimbatm> actually that would be much better, only 1 command to run :)
<gchristensen> https://github.com/NixOS/nix/issues/1551 :) could make a nixpkgs package nix-uninstsall-mac hehe
<zimbatm> yeah :)
<zimbatm> did you see the homebrew cask package for nix?
<gchristensen> that is actually a really good idea. I think I'll do that.
<gchristensen> hmm, nope! does it work? :D
<zimbatm> last time I tried, yes
<zimbatm> the idea was: `brew cask install nix` and you have nix installed
<zimbatm> cross-pollination
<gchristensen> awesome
<zimbatm> in my experience homebrew was still necessary
<gchristensen> oh yeah
<gchristensen> especially for GUI apps
<zimbatm> and `homebrew cask` is a nice way to install macOS apps
<zimbatm> the reason why I'm mentioning it is that you can also add uninstall instructions to it
<gchristensen> oh cool
<zimbatm> so that might become a recommended way for Darwin
<zimbatm> unfortunately I changed contract and don't have access to a macbook anymore
<gchristensen> the 17.09 channel went backwards in time
<gchristensen> it wentn 1fdca25ee8ca60e95d933e3ecce25e15fabc1999 -> 2231575a7ddd768fbce7d8f0c75926e5f1ee5c95 -> 1fdca25ee8ca60e95d933e3ecce25e15fabc1999
<niksnut> eh
<gchristensen> this was after I restarted all failed jobs on the latest eval
<copumpkin> zimbatm: we're doing our best to replace homebrew
<copumpkin> homebrew cask is farther off
<copumpkin> curious if there are major gaps you see in our coverage vs. homebrew's
<peti> domenkozar: Yes, new changes.
<zimbatm> copumpkin: when I still had a mac, 90% of my packages where sourced from nixpkgs but some where still problematic. from memory: anything with gpg like git-crypt, heroku
<domenkozar> peti: if you know how to set automatic builds for docker, I'm happy to hook that up
<zimbatm> there were the times where go programs could segfault, it was handy to have homebrew as a fallback
<peti> domenkozar: If you can give me access to the docker hub project, then I can set-up the auto-builds.
<zimbatm> peti: something like https://github.com/numtide/docker-nix ?
<zimbatm> or is it going to be pure nix?
<zimbatm> I don't mind giving you access and when it's ready we can move it to the nixos org
<peti> zimbatm: Hmm, that image seems to be an outdated version of what we have in the Nix repository in misc/docker.
<zimbatm> maybe, I had to make a couple of tweak to fix ssl issues
<peti> zimbatm: We have a decent Docker file in the Nix repo, but what we don't have is an auto-build on docker hub that provides the latest version of that image every time the Dockerfile changes in git.
<zimbatm> I don't think that's right, the version of nix is hard-coded in misc/docker
<peti> zimbatm: I'm not sure what you mean?
<zimbatm> docker hub maps the git tags to docker tags and master to :latest
<zimbatm> but every time master is being pushed here, it would still build the fixed version number that's pulled inside the Dockerfile
<zimbatm> it would be easier to maintain that in a separate repo so you can first do the nix release, the update the docker-nix repo with that release and tag it
<zimbatm> at least with the current approach
<zimbatm> ok I see the default profiles have changed
<peti> zimbatm: IMHO the current state is perfectly fine. "latest" refers to whatever is the latest version that we have in the docker image.
<zimbatm> I think it would be confusing to pull nixos/nix:1.12 and still get the 1.11 version
<peti> zimbatm: Nobody creates nixos/nix:1.12.
<MoreTea> domenkozar, peti I just played a bit with using the multi-stage Dockerfile image feature. It appears that we can bootstrap a pristine nix docker image quite easily using that.
<peti> zimbatm: The auto-build just pushes to "latest". Everything else would need manual triggers at the moment.
<zimbatm> in any case auto-build would already be an improvement
<zimbatm> ideally, the Dockerfile would build the nix code that's in the repo, using a multi-stage Dockerfile. then everything could map 1:1 to the repo code
<domenkozar> can we tell dockerhub to only build master?
<zimbatm> yes
<zimbatm> that would be a quick win
<MoreTea> domenkozar, you can set up rules like: this branch should be published under tag $X
<domenkozar> MoreTea: would that reduce image size? or what's the intention
<gchristensen> some discussions on solving the H.S. problem include reapplying a tighter sandbox to the build user (if possible, to be determined) which prevents forking, enumerating all the processes (using the atomic syscall KERN_PROC_UID) killing them all, and repeating this loop until there are no processes by the user.
shlevy has joined joined #nixos-dev
<gchristensen> copumpkin: where would I go to learn about sandbox_add_extension?
<copumpkin> the function is gone and this has all been gleaned from reverse engineering in the first place
<copumpkin> apple doesn't document any of that
<gchristensen> I thought you said sandbox_create_extensions was gone, not _add_extension
<copumpkin> there are a couple of docs I posted the other day from reverse engineering
<copumpkin> did I mention _add_extension? I don't see such a function
<gchristensen> you didn't mention _add_extension
<copumpkin> nm /usr/lib/libsandbox.dylib | grep _sandbox
<gchristensen> oh I see
<copumpkin> gchristensen, shlevy: might want to keep an eye on http://newosxbook.com/forum/viewtopic.php?f=7&t=17135
<gchristensen> great! I'll add these to the issue
<gchristensen> https://hydra.nixos.org/jobset/nixpkgs/trunk is reporting queued jobs on 1400788 but going to https://hydra.nixos.org/eval/1400788 reveals no queued jobs remaining
<MoreTea> domenkozar, its 182mb now
<MoreTea> which appears to be more than the original ones, hmmz.
<domenkozar> well you have to count all layers
<MoreTea> there is only one layer ;)
<MoreTea> Well, there is `scratch` as well, but it's empty.
<domenkozar> yeah current image is 177MB
<domenkozar> nix closure is 105MB
<domenkozar> once we remove perl from nix in 1.12 release
<domenkozar> it will go in half!
<MoreTea> :)
<gchristensen> anyone seen this bug with a phantom queued job?
<domenkozar> in hydra?
<gchristensen> yeah
<domenkozar> it's usually two things
<domenkozar> drv uses a feature that none of your machines has
<domenkozar> or it's on platform that you don't have slaves for
<domenkozar> 32bit usualy the culprit
<gchristensen> wouldn't it show up as queued, though?
<gchristensen> here we see one queued job: https://hydra.nixos.org/jobset/nixpkgs/trunk but here we see none: https://hydra.nixos.org/eval/1400788
<disasm> wait, perl is getting removed from nix? makes me happy :)
<domenkozar> disasm: it already is
<domenkozar> well, from runtime closure.
<domenkozar> gchristensen: it's in "new jobs"
<gchristensen> oohh
<gchristensen> odd
zraexy has joined joined #nixos-dev
<gchristensen> thank you, domenkozar :)
<domenkozar> yw :)
<gchristensen> wat
<domenkozar> I can't upgrade to 17.09 because of this
<domenkozar> :(
<domenkozar> old kernels don't work at all, 4.13 breaks workaround
<gchristensen> but
<gchristensen> how does it work for me
<domenkozar> you have nvidia card turned off?
<gchristensen> hrm I guess I do
<domenkozar> I mean the default is on
<domenkozar> if you turn it off via bumblebee then you get this
<domenkozar> hardware.nvidiaOptimus.disable = true;
<gchristensen> I don't know what I do
<gchristensen> oh! nixpkgs-unstable bumped!
<alp> domenkozar, oh so you had bumblebee working with the xps 9560?
<zimbatm> hmm but depends on cargo unstable
<zimbatm> seems doable but would require another 2 days of work with somebody that has rust knowledge
<zimbatm> why am I even trying to do this :p
<Mic92> zimbatm: I have, but I have other projects to finish first (at least this week).
<Mic92> zimbatm: we need cargo-unstable, I fear to support git properly.
<Mic92> Looking at the release cycle I think there will be a new version soon: https://github.com/rust-lang/cargo/releases
<taktoa> /join #nixos-blah
<taktoa> woops, didn't mean to put a preceding space there
<taktoa> I guess that's as good a way as any to float the idea of such a channel :-)
<gchristensen> what is -blah for? :)
<simpson> Good idea but I fear that it won't fix #nixos.
<taktoa> gchristensen: like haskell-blah
<gchristensen> oh
<clever> gchristensen: reguarding the high seira bug, what special powers might other signals have?, what if i SIGHUP or SIGUSR1 every process on the machine?
<copumpkin> niksnut: you thinking of expanding on the seccomp stuff to kill syscalls that most builds wouldn't need? or do you trust the namespacing stuff enough?
<copumpkin> would be nice if seccomp had a nicer front-end language like the mac sandboxing stuff
__Sander__ has quit [(Quit: Konversation terminated!)]
<niksnut> copumpkin: I did considered killing buildings instead of returning EPERM/ENOTSUP
<copumpkin> but things like disabling the shutdown syscall for example
<copumpkin> erm wrong one
<copumpkin> sys_reboot, settimeofday, etc. :P
goibhniu has quit [(Ping timeout: 255 seconds)]
<gchristensen> can unpriveleged users call those? interesting :)
<gchristensen> can graham learn to spell "unprivileged"? let's find out
<copumpkin> I'd hope not :) mostly just wondering if we want to do a paranoid seccomp call in case other mechanisms get circumvented
<gchristensen> I, for one, hope that I can learn to spell
<copumpkin> lol
MichaelRaskin has joined joined #nixos-dev
<LnL> can sombody restart the aborted jobs of https://hydra.nixos.org/eval/1401005
<gchristensen> yeah
<gchristensen> doesn't look like it did much good, LnL
<LnL> :/
<LnL> it does look better
<gchristensen> oh
<gchristensen> 100 passed
<gchristensen> but 386 still aborted
<LnL> euh
<LnL> I'm seeing +38 and 346 aborted
<gchristensen> oh 346 :P
<gchristensen> but I restarted like ~490 aborted
<LnL> yeah
<disasm> is advertising a freelancer bounty appropriate for nix-devel? at least they aren't asking for money I guess.
<MichaelRaskin> I cannot deny that the bounty being advertised is relevant for Nixpkgs development.
<clever> gchristensen: hydra emailed me about https://hydra.nixos.org/build/61683847 failing, but the logs for qtbase say it didnt fail, what happens if you restart it?
<gchristensen> hmm not sure
<gchristensen> should I restart it?
<clever> yeah
<gchristensen> done
<clever> gchristensen: its still listing as aborted
jtojnar_ has joined joined #nixos-dev
jtojnar has quit [(Ping timeout: 240 seconds)]
JosW has quit [(Quit: Konversation terminated!)]
jtojnar_ is now known as jtojnar
<copumpkin> seems up our alley re: the distributed build verification thing
<copumpkin> their merkle tree thing is unnecessary with nix
<copumpkin> at least with our setup
<MichaelRaskin> Well, we would need bit-perfect builds
<MichaelRaskin> And then all that stuff about tracking the repository fate so that a single-machine compromise doesn't poison it (including GitHub compromise.)