sphalerite changed the topic of #nixos-dev to: NixOS Development (#nixos for questions) | NixOS 19.09 now in beta! https://discourse.nixos.org/t/nixos-19-09-feature-freeze/3707 | https://hydra.nixos.org/jobset/nixos/trunk-combined https://channels.nix.gsc.io/graph.html | https://r13y.com | 19.09 RMs: disasm, sphalerite | https://logs.nix.samueldr.com/nixos-dev
justanotheruser has quit [Ping timeout: 245 seconds]
drakonis has quit [Ping timeout: 240 seconds]
ris has quit [Ping timeout: 265 seconds]
orivej has joined #nixos-dev
<bgamari_> is it just me or is buildGoModule completely broken?
<bgamari_> it looks like the dependencies aren't actually fetched
<bgamari_> e.g. Fetching file:///nix/store/npxv14jzh83n8yxw4lpi9hdwl7h88d53-gitlab-shell-go-go-modules/github.com/mattn/go-shellwords/@v/v0.0.0-20190425161501-2444a32a19f4.info
<bgamari_> go: github.com/mattn/go-shellwords@v0.0.0-20190425161501-2444a32a19f4: open /nix/store/npxv14jzh83n8yxw4lpi9hdwl7h88d53-gitlab-shell-go-go-modules/github.com/mattn/go-shellwords/@v/v0.0.0-20190425161501-2444a32a19f4.info: no such file or directory
<bgamari_> /nix/store/npxv14jzh83n8yxw4lpi9hdwl7h88d53-gitlab-shell-go-go-modules was created but is completely empty
justanotheruser has joined #nixos-dev
drakonis_ has joined #nixos-dev
drakonis_ has quit [Read error: Connection reset by peer]
drakonis_ has joined #nixos-dev
drakonis has joined #nixos-dev
drakonis_ has quit [Ping timeout: 246 seconds]
niksnut has quit [Ping timeout: 240 seconds]
niksnut has joined #nixos-dev
drakonis_ has joined #nixos-dev
drakonis has quit [Ping timeout: 246 seconds]
drakonis has joined #nixos-dev
niksnut has quit [Ping timeout: 276 seconds]
drakonis_ has quit [Ping timeout: 240 seconds]
niksnut has joined #nixos-dev
drakonis_ has joined #nixos-dev
pie__ has quit [Ping timeout: 245 seconds]
jonringer has joined #nixos-dev
drakonis_ has quit [Ping timeout: 276 seconds]
pie_ has joined #nixos-dev
ivan has quit [Quit: lp0 on fire]
harrow has quit [Quit: Leaving]
harrow has joined #nixos-dev
ivan has joined #nixos-dev
pie_ has quit [Ping timeout: 276 seconds]
niksnut has quit [Quit: Lost terminal]
FRidh has quit [Ping timeout: 246 seconds]
dmj` has quit [Ping timeout: 276 seconds]
dmj` has joined #nixos-dev
jonringer has quit [Ping timeout: 240 seconds]
pie_ has joined #nixos-dev
<tazjin> Hm
<eyJhb> tazjin: but that would require all new services that comes in PRs to have stricter requirements, right? Because having sane defaults in the form of isolation seems like it would be quite difficult
<tazjin> Yes, probably
<tazjin> I'm not sure if there are quick wins available by changing something basic in the systemd module
<etu> But it would be nice...
<tazjin> DynamicUser might work across everything?
<tazjin> As for patches, what if we had a global hardening toggle that people can gate extra isolation (per service) behind?
<eyJhb> Thinking dynamicuser might work as well yes, and I seem to remember someone was working on something, regarding what sounds like could be used for this. - But it very much depends on the application most of the time, e.g. chroot and where it needs to write..
<eyJhb> What would such a global hardening toggle do? Also, it would be something like.. systemd.services.<name>.harden = true;?
<tazjin> One level up I think (hence global)
<tazjin> it would enable all secure defaults we can get (such as dynamic users) on all services and let service modules gate specific more secure config behind it
<tazjin> so users can opt-in and deal with any potential breakage then
danderson has joined #nixos-dev
<eyJhb> Got confused by "per service", but that might work. Could be opt-in to begin with, and after a safe amount of testing it might be able to be default. - Would this calify for a RFC, or just a PR?
<tazjin> RFC I think
<tazjin> To determine which options we are even talking about
<eyJhb> Just spitballing here, but maybe a approach could also be taken, to put everything into containers? But that would require quite some work...
<eyJhb> Also because nixos containers are currently somewhat funky
<tazjin> danderson pointed out that we'd need to consider things such as runtime state access if dynamic users are enabled, systemd can handle that via state directories - the question is what percentage of services defaults to a sane state location
<eyJhb> Testing that would be quite difficult
<danderson> hi! So, the reason I wished for this on twitter is that I'm currently putting everything in nixos containers, and it's a bit clunky :)
<eyJhb> Or, it somewhat would
<eyJhb> danderson: containers ?
<tazjin> danderson: somewhat orthogonal to this discussion, are you aware of #spectrum?
<fpletz> tazjin: I agree that this would be awesome but I can guarantee you that this would break nearly every service so it's a labour-intensive process because every service needs manual testing
<danderson> tazjin: I am now!
<fpletz> also note that there are still weird systems bugs with dynamicuser in containers with userns enabled
<fpletz> *systemd
<danderson> maybe I'm just more paranoid than average. My threat model is simply that I assume my network services will have an RCE vulnerability at some point, so I want as much sandboxing as systemd can offer without breaking the daemon
<eyJhb> There are more stuff in containers that works funky as well, e.g. bindMounts
<tazjin> fpletz: dynamicuser *in* containers?
<{^_^}> systemd/systemd#4441 (by keszybz, 2 years ago, closed): systemd-nspawn -U seems incompatible with invocation IDs
<globin> whoops wrong one
<{^_^}> systemd/systemd#13622 (by globin, 1 day ago, open): systemd-nspawn -U is incompatible with RuntimeDirectory and DynamicUser
<danderson> some of it (drop most capabilities, prevent re-acquiring them) should work pretty universally (except for daemons that need the privs, of course). Others (like chroots with dynamic users) will take more tweaking to work right
<eyJhb> danderson: maybe, I am as well, but sometimes you give up on it
johanot has joined #nixos-dev
<eyJhb> Yeah danderson, but how would you determine if the service work correctly when you drop capabilities?
<danderson> I'm definitely not suggesting turning it on universally for everything at once. My question was more: if I start sending patches to tighten up security on stuff, is that welcome, or not a design goal?
<eyJhb> Without manually testing :/
<globin> it is very much welcome
<fpletz> danderson: that would be very welcome!
<danderson> there's a baseline you can comfortably apply, which is seccomp rules that match Docker's default seccomp profile
<danderson> that's pretty much just "disable obsolete/dangerous syscalls", to reduce the kernel 0day surface
<eyJhb> I still like tazjin idea, of having some switches that could be enabled, to ease maintaince. If we can have security rules across systemd services, that would be awesome
<danderson> when they added the profile to docker, they did a lot of testing on a lot of software, and concluded that it all works fine :)
<eyJhb> danderson: docker sane defaults still screws up some stuff, but I might also be doing weird stuff in my containers....
<danderson> so, my worry with adding switches is that it's yet-another orthogonal switch that changes all derivations, unless I'm not understanding?
<eyJhb> tazjin said to take it up a step, I suggest it for each service
<tazjin> it changes the module configurations, not necessarily the service derivations
<danderson> in the absence of automated testing, the next best thing is having enough people using the settings to quickly detect when it breaks
<tazjin> so you'd have a `services.defaultHardening = true;` or something which flips on dynamic users, state dirs and other stuff automatically for all services
<danderson> (well, IMO anyway)
<danderson> oh, hmm
<danderson> I think that would break a lot of stuff. But I'd have to think about it.
<tazjin> (it'd be useful to determine all options which are relevant here)
<tazjin> yes, that's the expectation
<tazjin> thus, gate it behind a toggle
<danderson> so the idea is, harden everything by default, but allow each service to replace with its own configuration, or?
<tazjin> hmm, I guess you could just go and flip it on across all services even without this toggle and see what happens
<tazjin> yes
<tazjin> also, I'll be afk for a bit
<danderson> I see. I worry that the result would just be "congrats, system is borked". But that might be useful for testing :)
johanot has quit [Quit: WeeChat 2.4]
<danderson> I have to head to sleep now. Thanks for the discussion! I'll check back in tomorrow.
<eyJhb> 10 AM, wish it was me...
<eyJhb> But wouldn't it somewhat make more sense, instaed of just having a global switch? Then each service/PR could specify what it needs to funciton, instead of a global state? - Or a combination of both
johanot has joined #nixos-dev
johanot has quit [Client Quit]
<eyJhb> Wouldn't it actually somewhat be easier to put into containers?
johanot has joined #nixos-dev
johanot has quit [Client Quit]
johanot has joined #nixos-dev
johanot has quit [Quit: WeeChat 2.4]
johanot has joined #nixos-dev
johanot has quit [Client Quit]
FRidh has joined #nixos-dev
johanot has joined #nixos-dev
johanot has quit [Client Quit]
johanot has joined #nixos-dev
__monty__ has joined #nixos-dev
__Sander__ has joined #nixos-dev
ivan has quit [Remote host closed the connection]
allan has quit [Ping timeout: 245 seconds]
ivan has joined #nixos-dev
allan has joined #nixos-dev
delroth has quit [Ping timeout: 245 seconds]
ashkitten has quit [Ping timeout: 245 seconds]
tv has quit [Ping timeout: 245 seconds]
ashkitten has joined #nixos-dev
delroth has joined #nixos-dev
FRidh has quit [Ping timeout: 265 seconds]
tv has joined #nixos-dev
FRidh has joined #nixos-dev
<delroth> I think it would be nice by starting to have a policy on whether we want to have these hardening options in nixos systemd service configs
<delroth> I have a few custom patches in my nixpkgs fork that I didn't bother upstreaming because 1. it's like 10 lines of systemd config cruft per service for something relatively few people care about; 2. it's hard to test in every single scenario, I can vouch that it works for my use case but not in all use cases
<delroth> (also hi danderson! :) )
<delroth> maybe one path we could go with is 1. provide a "systemd.services.xxx.harden = true;" switch which sets mkDefault values for all these hardening options (with the most hardened as default); 2a. let users set harden=true in their nixos configuration to figure out what breaks and relax those settings; 2b. have the hardened profile set harden=true on some chosen daemons; 3. upstream the settings
<delroth> that need to be relaxed and set harden=true by default on those services
<delroth> there are many issues with that though: for one, it's long manual work that isn't future-proof, i.e. we can't really turn on new hardening options automatically without fear of breaking things
* emily would love to have things like this upstream
<emily> behind an option seems reasonable, though it's not like NixOS doesn't randomly break features of software anyway >_>
niksnut has joined #nixos-dev
<fpletz> delroth: thanks, your last point is the reason why I would advise not to add a harden convenience option but do it on a per service basis
<fpletz> we can't reliably test every code path in services so at least real users should test or implement this
<delroth> the harden convenience option wouldn't be global but per-service in my proposal -- it's mostly a way to avoid copy-pasting the same 10 lignes everywhere
<clever> delroth: that does sound like a nice and simple way to handle it
<clever> and the default for systemd.services.xxx.harden could also change in the future, since you can also just opt-out by setting it to false instead
<fpletz> but that set of hardening optiona would then be more or less fixed
<fpletz> clever: how do you test for that?
<clever> in the future, when a large percentage of services are setting harden = true;, you just commit and change the default
<clever> and then set harden = false; on anything that gets reported as broken
<clever> or fix them
janneke has quit [Ping timeout: 250 seconds]
janneke has joined #nixos-dev
<Taneb> I just created a PR fixing a package that has no maintainers
<qyliss> want to maintain it? :3
<qyliss> s/3/;/
<qyliss> err,
<qyliss> whatever
<Taneb> Well, no, I have little interest in it other than it's a broken thing which it turned out I could fix
<Taneb> But if no-one else will...
<Taneb> My question was more "Who do I ping about it?"
<qyliss> whoever you want, I guess
<qyliss> or people who maintain closely related / dependent packages, if you feel like putting in the effort to find them
<qyliss> or people who've previously worked on this package
<Taneb> It's an obscure compiler for a research language, with nothing built by it in nixpkgs
<qyliss> what's the package?
<Taneb> manticore
<{^_^}> #69350 (by Taneb, 14 minutes ago, open): manticore: 2018.09.29 -> 2019.09.20
<qyliss> I'll review it
<qyliss> if that works for you
<Taneb> That works
<qyliss> Looks like a reasonably safe PR
<qyliss> gosh, do they really not tag their releases
<Taneb> Nope
<Taneb> Well, not that I could tell in about 5 minutes of looking
<Taneb> Certainly not on GitHub
<Taneb> Their install instructions are just "clone from GitHub!"
<qyliss> Oh, I see
<qyliss> So did you just update to master?
<Taneb> Yeah
<qyliss> gotcha
drakonis_ has joined #nixos-dev
drakonis_ has quit [Read error: Connection reset by peer]
drakonis_ has joined #nixos-dev
drakonis has quit [Ping timeout: 240 seconds]
psyanticy has joined #nixos-dev
<ddima> Taneb: when I happen to be in similar situations I also poke the last committer, even if just for second opinion.
<qyliss> oh i totally got distracted
<Taneb> qyliss: could I ask you to also backport that PR?
<qyliss> yeah will do
<qyliss> i got distracted again
<qyliss> but rigth now!
<qyliss> I shall review!
<Taneb> ...actually, I assumed that you were the same person as Mic92 who has reviews the PR. Now I'm suddenly not sure that's the case
<qyliss> no lol I just reviewed it now before noticing Mic92 had already got to it
<qyliss> @Mic92 on GH is Mic92 here ;)
<qyliss> But I can do the backport at least
<qyliss> Taneb: backported
<Taneb> Great, thank you :D
<Mic92> Taneb: Oh, did I forgot to backport it?
<Taneb> qyliss++
<{^_^}> qyliss's karma got increased to 10
<Taneb> And also Mic92++
<{^_^}> Mic92's karma got increased to 12
<Taneb> Mic92: I didn't see you having backported it
<Mic92> Maybe i got distracted by work :)
<Taneb> Hmm, I can't reproduce https://hydra.nixos.org/build/102013548
<Taneb> It even seems to be cached
<Taneb> As a success
<arianvp> globin: how much longer are yo gonna be at the mayflower office today?
drakonis has joined #nixos-dev
<globin> quite a while probably
<arianvp> are you gonna eat there?
drakonis_ has quit [Ping timeout: 246 seconds]
<globin> we had something from a takeaway at lunch, no plans for dinner yet
<arianvp> ok ill probably not join anymore today. got some other obligations to attend to
<arianvp> but ill be hacking tomorrow as wel.. and currently remotely
<globin> ok, yeah I'll be ready here at around 10 tomorrow again
xwvvvvwx has quit [Quit: ZNC 1.7.4 - https://znc.in]
xwvvvvwx has joined #nixos-dev
orivej has quit [Ping timeout: 276 seconds]
jonringer has joined #nixos-dev
justanotheruser has quit [Ping timeout: 276 seconds]
__monty__ has quit [Ping timeout: 246 seconds]
<arianvp> gchristensen: you built those packet nixos images right?
<gchristensen> yeah
<{^_^}> #49534 (by Mic92, 46 weeks ago, open): Networkd cannot match interface types
<arianvp> (Ignore the issue name; someone came into the issue with some networking issues)
<arianvp> on packet; i've been trying to debug it but cant find a culprit
<gchristensen> uh oh, can you give me a 30s summary?
<arianvp> network takes a few minutes to come up
<arianvp> with the default packet configuration on release-19.09
<arianvp> so the gateway is giving ARP responses to the server, but they dont end up in the ARP table of the server for whatever reason
<arianvp> so the server doesn't learn its neighbours
<arianvp> maybe we should look at it with someone from packet. this is a little bit beyond my comfort zone :')
<clever> arianvp: i think ive seen similar happen when the bond driver in nixos was bork
<arianvp> it bissected to thise change https://github.com/NixOS/nixpkgs/commit/1f03f6fc43a6f71b8204adf6cd02fb3685261add which confuses me a bit :)
<clever> arianvp: that could also do it, packet needs bonding configured, and has to know the IF names when configuring it
<arianvp> we explicitly tell what ifnames to bond. gchristensen is generating an explicit bond
<clever> arianvp: but if the ifnames your saying to bond, dont exist anymore, what happens?
<arianvp> the ifnames exist though.
<gchristensen> I think we could get some Packet people in this channel in a few hours
johanot has quit [Quit: WeeChat 2.4]
<arianvp> could also do it in the slack. whatever works
<arianvp> but yeh. would be kinda not nice if we break packet support with 19.09 =)
<arianvp> can we detach a thread in github into a new issue? because I want to close the original issue as it's fixed
orivej has joined #nixos-dev
<gchristensen> I don't think so
<gchristensen> maybe just open a new issue
<arianvp> k done
justanotheruser has joined #nixos-dev
mmlb has joined #nixos-dev
* mmlb waves
<gchristensen> hey mmlb
<gchristensen> arianvp: ^
* mmlb checks out the net.ifnames=0 commit mentioned in history
<Taneb> Something seems to have gone wrong with https://hydra.nixos.org/build/102072744
st8less has joined #nixos-dev
orivej has quit [Ping timeout: 240 seconds]
<Taneb> "warning: unable to download ..."
__Sander__ has quit [Quit: Konversation terminated!]
<arianvp> I currently cannot really debug anything as master nixos doesnt boot machines
<arianvp> and im gonna have some dinner now too :)
<gchristensen> :o
<emily> arianvp: wow, the predictable networking fiasco really doesn't stop giving, huh
<{^_^}> #69365 (by arianvp, 5 minutes ago, open): update-users-groups.pl is broken on master. System doesn't boot
<emily> re that bisect
<arianvp> at least not for me :P
<arianvp> emily: yeh but im 50% sure this one is unrelated
mmlb has quit [Remote host closed the connection]
<Taneb> 50% sure is a very unsure amount of sure
<arianvp> correct
mmlb has joined #nixos-dev
<emily> are you also 50% sure it's related?
<arianvp> maybe
<arianvp> mmlb: i'll be back in a few hours. otherwise available tomorrow
<mmlb> I'll be around for a while. I've pinged some peeps with better network chops to join here.
ixxie has joined #nixos-dev
<sphalerite> globin infinisil gchristensen andi-: belated +1 on changing mkRemovedOptionModule to an error generally, although I think I'd prefer removing mkRemovedOptionModule completely
<sphalerite> maybe
<infinisil> Why remove it and how?
<gchristensen> I would very strongly prefer not doing that, and instead start by making it a warning in one release and an error in the next, except in cases where the warning step cannot be taken due to complexity
<samueldr> +1, warn that it *will* not work while continuing to work, and break the config to force a user choice
jonringer has quit [Ping timeout: 268 seconds]
drakonis_ has joined #nixos-dev
drakonis has quit [Ping timeout: 240 seconds]
__monty__ has joined #nixos-dev
drakonis_ has quit [Ping timeout: 246 seconds]
<arianvp> is there any state preserved between nixos test vms?
<arianvp> my /var/lib/nixos/uid-map is corrupted when I start a nixos test and all the tests fail
<arianvp> wondering if it might stuck around from a previous test?
<gchristensen> okay so globin and I did a quick video call to talk about these removed options thing (cc samueldr) and I agree we should fail. the specific case here is an option was removed, and a new option of a different structure was created, ie: not a rename. this means the configuration needed was totally ignored and a very broken deploy was allowed to go out
drakonis_ has joined #nixos-dev
justan0theruser has joined #nixos-dev
drakonis has joined #nixos-dev
justanotheruser has quit [Ping timeout: 245 seconds]
st8less has quit [Ping timeout: 276 seconds]
justan0theruser has quit [Ping timeout: 265 seconds]
<fpletz> +1 for fail on mkRemovedOptionModule
marek has quit [Ping timeout: 276 seconds]
marek has joined #nixos-dev
<aanderse> gchristensen: awesome
justan0theruser has joined #nixos-dev
st8less has joined #nixos-dev
pie_ has quit [Ping timeout: 276 seconds]
ris has joined #nixos-dev
<sphalerite> not sure whether that should go into 19.09 though?
yorick has quit [Quit: WeeChat 2.4]
yorick has joined #nixos-dev
<samueldr> if the breaking change exists in it, it should
<arianvp> mmlb: I guess the best course of action is to see if you can buid a 19.09 variant of the packet nixos image
<arianvp> and see if some of the network people can reproduce it
pie_ has joined #nixos-dev
orivej has joined #nixos-dev
<mmlb> Thats all on gchristensen actually, he does all the hard work we just integrate it in!
psyanticy has quit [Quit: Connection closed for inactivity]
mmlb0 has joined #nixos-dev
mmlb has quit [Remote host closed the connection]
mmlb0 is now known as mmlb
ixxie has quit [Ping timeout: 276 seconds]
mmlb has quit [Quit: The Lounge - https://thelounge.github.io]
mmlb has joined #nixos-dev
arianvp has quit [Quit: WeeChat 2.6]
arianvp has joined #nixos-dev
<ivan> should I open a new PR to remove the tags and reviewers from https://github.com/NixOS/nixpkgs/pull/69378
<{^_^}> #69378 (by ivan, 1 hour ago, open): kernel/common-config: enable SCHED_DEBUG
<ivan> thanks gchristensen
<gchristensen> yep
<ivan> pressing Enter on GitHub sometimes creates a PR before I type in a description :(
__monty__ has quit [Quit: leaving]
<ivan> is the eval failure on https://github.com/NixOS/nixpkgs/pull/69388 my fault
<{^_^}> #69388 (by ivan, 13 minutes ago, open): kernel/common-config: enable INET_{TCP,UDP,RAW}_DIAG and INET_DIAG_DESTROY
<gchristensen> grahamcofborg-eval — The branch this PR will merge in to does not cleanly evaluate, and so this PR cannot be checked.
<ivan> it's complaining about attribute 'dev' missing, at /var/lib/ofborg/checkout/repo/38dca4e3aa6bca43ea96d2fcc04e8229/mr-est/eval-2-shlevy.ewr1.nix.ci/pkgs/development/compilers/terra/default.nix:37:41
drakonis_ has quit [Ping timeout: 240 seconds]
drakonis_ has joined #nixos-dev
justan0theruser has quit [Quit: WeeChat 2.4]
justanotheruser has joined #nixos-dev
st8less has quit [Ping timeout: 240 seconds]
<edef> so i've rebased https://github.com/NixOS/nixpkgs/pull/59806 for the nth time
<{^_^}> #59806 (by dtzWill, 22 weeks ago, open): openssh: 7.9p1 -> 8.0p1
<edef> i'd prefer signoff from someone, but other than that i don't really see reason not to merge
<arcnmx> mm I've been eyeing that for a while now hoping it could be merged ><
<samueldr> edef: only thing I see is that this is happening after the branch-off for 19.09, but updates the 19.09 release notes...
<samueldr> ... which may be fine if the backport is wanted and approved by the RMs
<samueldr> I don't know if this update could be causing unexpected failures wrt stability and backports
justan0theruser has joined #nixos-dev
justanotheruser has quit [Ping timeout: 240 seconds]
<edef> samueldr: yeah the plan was to have this in for 19.09
<edef> samueldr: should i retarget this for .. 20.03?
<edef> this does mean we're stuck supporting HPN for another 6mo
<samueldr> I personally don't have an opinion either way, well, maybe towrads landing this in 19.09
<samueldr> do you have the confirmation form disasm or sphalerite that it's still fine?
<samueldr> that's the only hangup I would have
<samueldr> (I think it's likely to be fine)
<edef> i don't have any confirmation from anyone right now
<edef> disasm, sphalerite: either of your judgment appreciated, i guess?