<LnL>
error: could not set permissions on '/nix/var/nix/profiles/per-user' to 755: Operation not permitted
<gchristensen>
sounds like a bug in dealing with a CVE
<LnL>
oh, the profile creation stuff?
<gchristensen>
yeah
<LnL>
sounds plausible, I'll take a look tomorrow
<gchristensen>
thank you
justanotheruser has quit [Ping timeout: 272 seconds]
<LnL>
anyway, that's a regular build in a separate store
<LnL>
not using nixpkgs does mean you have to introduce implicit dependencies, but for trivial things that's often fine
<LnL>
or you can inject /nix/store paths explicitly
<LnL>
err it's a typo
bhipple has quit [Ping timeout: 258 seconds]
bhipple has joined #nixos-dev
<infinisil>
Hm so with the per-user/per-group secret thing, to be able to access a secret one then needs to know whether it's my users secret (in which case I can use per-user/$USER) or my groups secret (in which I can use per-group/$GROUP)
<infinisil>
There's no general "Give me secret foo" anymore
<infinisil>
Is that a problem? Maybe not
<LnL>
what if you share the state/profile between all of them and only change the store
justanotheruser has joined #nixos-dev
<gchristensen>
you could have a module which grants access to the secret by virtue of handing back a store path which is a symlink to the /run/keys/... location
<infinisil>
gchristensen: Doing that already, but whether per-user/per-group should be used depends on what user tries to access it during runtime
<LnL>
shouldn't permissions be bound to the secret instead?
<gchristensen>
the opposite is true: it depends on what the administrator authorises
<infinisil>
LnL: Doing that too, but I want to restrict access to per-user/per-group so only those can even list files in there
<gchristensen>
LnL and I are saying the same thing
<infinisil>
gchristensen: Currently it works without problem because a single secret path either has a working user or a working group, and the service needs to be in either for it to access it
<gchristensen>
the person writing the config should determine which one it goes in to
<infinisil>
Ah I see
<infinisil>
So either it's a user-owned secret or a group-owned one
<infinisil>
exclusively
<gchristensen>
the admin says which, your code has no opinion, and makes no guesses
<LnL>
yeah, either I allow the nginx user to access the ssl cert or I allow the www group to access it
<LnL>
that's determined for the secret upfront
<infinisil>
Alright yeah I think that makes sense
<infinisil>
Nice
<infinisil>
Thanks for all the feedback btw, LnL++ and gchristensen++ :)
<{^_^}>
LnL's karma got increased to 26, gchristensen's karma got increased to 225
<LnL>
unless you want to allow multiple things, but then you're back in xattr territory and I don't think that's really necessary
<gchristensen>
thank you for asking, and exploring :)
<infinisil>
Now I wish I could have a type like `data SecretOwner = User String | Group String` in the module system..
<gchristensen>
{ tag = "user|group"; value = "..."; }
<LnL>
nix.conf uses user and @group
<gchristensen>
oh right
<infinisil>
Ohh
<LnL>
not sure if that's used anywhere else tho
<infinisil>
That's great, I'll use that
<infinisil>
Well
<infinisil>
Maybe
<infinisil>
`secrets.foo.user = "user"` and `secrets.bar.group = "group"` are nicer, along with an assertion to guarantee not both are set
<gchristensen>
+1
<adisbladis>
Just a random thought that popped into my head: Wouldn't it be nice if Nix had a concept of what a secret is that could be propagated via string context.
<adisbladis>
That could ensure a secret never ends up in the store.
<gchristensen>
imo no, it wouldn't, because secrets shouldn't be in .nix files
<infinisil>
Hm, well a Nix file isn't any more or less secure than other file types
<adisbladis>
gchristensen: Good point :)
<infinisil>
gchristensen: Why shouldn't secrets be in .nix files?
<adisbladis>
Because secrets are not config, they are state.
<LnL>
a secret value shouldn't be but something opaque could work
<gchristensen>
true, LnL
<infinisil>
adisbladis: Why are secrets state and not config? Is there a reason or could it just be that as Nix people we're used that config is world-readable?
<LnL>
but I think fully integrating secrets in a correct way would have a lot of caveats
<infinisil>
s/used/used to
<infinisil>
Well I guess if Nix implements secrets they would at least stick around until the next GC
<gchristensen>
infinisil: the lifecycle of config is totally different compared to secrets
<gchristensen>
tokens may last 10 years or 10 seconds
<infinisil>
I see, makes sense yeah
<infinisil>
Rollbacks would be a problem, as you wouldn't want to rollback to an old certificate or so
<gchristensen>
right
<gchristensen>
or start accepting those compromised SSH keys again
<infinisil>
This makes me think: A system generation could be a *set* of different profiles. One profile for the config, one for (at least long-lasting) secrets, one for the hardware config
<infinisil>
This lets you upgrade/rollback each profile separately
<aanderse>
oh looks like i came online at the right time... interesting conversation about secrets :)
<infinisil>
E.g. you could rollback through hardware upgrades with this (by only rolling back the config profile, not the hardware one)
<infinisil>
Each independent thing that influences your system would have its own profile
<infinisil>
Another example could be a website API: The API can change over time, you don't have control over it. You wouldn't want to rollback the API you assume in your config code
<infinisil>
I think conceptually this makes a lot of sense
<gchristensen>
you're striking at the natural tension of NixOS
<infinisil>
Oh, one way to solve this is to not worry about profiles and generations at all. Instead you just redeploy to the machine, even for rollbacks
<infinisil>
So instead of using separate profiles, you can just use a local Nix file to track changes over time
<gchristensen>
also a valid approach
<gchristensen>
but long-lived secrets are dying, rapidly cycled secrets are the future
drakonis has quit [Ping timeout: 255 seconds]
<infinisil>
Probably not *all* long-lived secrets right?
<aanderse>
i work with some people who i never thought would adopt letsencrypt (actually mainly because it is a short lived secret)
<aanderse>
and we ended up almost entirely switching to letsencrypt
<aanderse>
we have a full wildcard cert... but we don't use it anywhere we don't absolutely have to
<aanderse>
so i'm inclined to agree with gchristensen on that one
<adisbladis>
aanderse: Letsecrypt did a lot of things right to get to that point though :)
* adisbladis
remembers the dark times before LE
<gchristensen>
infinisil: not all, but almost-all, surely
<infinisil>
But even with letsencrypt, the CA that signed their cert has a very long-lived secret key
<adisbladis>
Cert management was annoying as hell
<gchristensen>
dynamically allocated secrets are too valuable
<gchristensen>
sure
<adisbladis>
infinisil: Well, their root cert is.
<adisbladis>
They also have shorted lived keys that actually do the signing.
<infinisil>
Ah
<gchristensen>
managing those secrets is even harder than what we're talking about. they're doing key ceremonies with people from 3 continents showing up in a faraday cage underground once every year to present biometrics, physical token,s and passwords
<adisbladis>
As a CA you're required to use HSMs iirc, no one at LE actually has the root cert :>
<gchristensen>
yeah that too :)
<gchristensen>
(but those key ceremonies do happen, even with HSMs)
<infinisil>
Also, GPG/keybase/other identities are meant to be very long lived, or can that change?
<andi->
I recommend watching the recordings from the DNS root key signing
<gchristensen>
infinisil: some people thin kGPG keys should be shorter lived but .... :P
bhipple has quit [Read error: Connection reset by peer]
<infinisil>
Maybe let's say that short-lived keys should be used when possible, but there are applications where long-lived ones are necessary
<gchristensen>
sure
<gchristensen>
no doubt
<gchristensen>
I say that more from the perspective of: plan for dynamic secrets
* infinisil
keeps that in mind
<infinisil>
Oh, the user/group-exclusive secret permissions now remind me of how the acme module works
<adisbladis>
Please make redirects a 302, otherwise it's possible these screw ups are cached.
<adisbladis>
I know curl doesn't cache the redirects, but other clients may.
<niksnut>
garbas: ^
<andi->
niksnut: 2a03:b0c0:3:d0::d24:5001 is the corresponding AAAA address, that is documented somewhere.. I did that setup some 6 months ago for test site of mine.
<emily>
would anyone like to take a look at/potentially merge this, now that it has approvals? (enabling x86-32 emulation on the hardened kernels) https://github.com/NixOS/nixpkgs/pull/82006
<ajs124>
emily: some of the related issues around that are interesing. I remember running into this and enabling it, but I'm not sure if we should enable this for everyone. I'll comment on the PR.
janneke has quit [Quit: janneke quits Mes'sing]
janneke has joined #nixos-dev
janneke has quit [Read error: Connection reset by peer]
janneke_ has joined #nixos-dev
<samueldr>
should I write a proposal, detailed or not, if I wanted Mobile NixOS to have a "tested" jobset that would be used to (1) keep a known cross-compiling channel for stage-1 (2) track newly introduced issues with cross-compilation ?
<gchristensen>
the idea isn't a tested jobset, instead the idea is a channel?
<samueldr>
well, one comes from the other, right?
<gchristensen>
having a "tested" job is nothing special on its own :)
<samueldr>
sure :)
<samueldr>
but I was mainly asking on the org's hydra
<samueldr>
otherwise I can manage that all elsewhere
<samueldr>
I've been realising that I keep using an older checkout all the time to hack on stuff, but that's not good for other people trying it, since it generally won't build
<samueldr>
well, currently won't build*
janneke_ is now known as janneke
<samueldr>
oh, I know what was missing from my original question: "on the organization's hydra"
ris has joined #nixos-dev
justan0theruser is now known as justanotheruser
Jackneill has quit [Remote host closed the connection]
<lovesegfault>
Profpatsch: IIRC that doesn't work very well
<gchristensen>
zimbatm: finally a reason to bust out my K80s!
bhipple has quit [Read error: Connection reset by peer]
andi- has quit [Ping timeout: 268 seconds]
bhipple has joined #nixos-dev
elvishjerricco has quit [Remote host closed the connection]
lightbulbjim has quit [Remote host closed the connection]
cbarrett has quit [Remote host closed the connection]
nh2 has quit [Remote host closed the connection]
carter has quit [Remote host closed the connection]
johanot has quit [Remote host closed the connection]
feepo has quit [Remote host closed the connection]
<Profpatsch>
gchristensen: read that as Kuberneteuberneteuberneteuberneteuberneteuberneteuberneteuberneteuberneteubernetes
carter has joined #nixos-dev
<gchristensen>
lol!
feepo has joined #nixos-dev
<Profpatsch>
(that’s exactly 82 chars btw)
<gchristensen>
nice
cbarrett has joined #nixos-dev
elvishjerricco has joined #nixos-dev
nh2 has joined #nixos-dev
lightbulbjim has joined #nixos-dev
johanot has joined #nixos-dev
noonien has quit [Write error: Connection reset by peer]
teehemkay has quit [Remote host closed the connection]
kalbasit has quit [Remote host closed the connection]
sdier has quit [Remote host closed the connection]
tazjin has quit [Remote host closed the connection]
alunduil has quit [Remote host closed the connection]
c00w has quit [Remote host closed the connection]
aria has quit [Remote host closed the connection]
rajivr___ has quit [Remote host closed the connection]
ixxie has quit [Ping timeout: 265 seconds]
<samueldr>
sorry, don't want to nag, but who should I involve if I want to propose running mobile nixos builds (can be at a lower frequency) on the org's hydra?
<samueldr>
most of it should help with tracking issues with cross-compilation
<gchristensen>
samueldr: sorry, I'm not sure what it is you're asking for :x just a jobset? we can do a jobset :)
teehemkay has joined #nixos-dev
tazjin has joined #nixos-dev
<samueldr>
I'm not sure what I'm asking for since my hydra lingo is maybe not the best, but I figure project+jobset
<gchristensen>
you bet!
<gchristensen>
ping me in 1h :) doing a small server thing, then dinner
<samueldr>
great, will do, maybe a bit later since I have to do stuff to
<samueldr>
too*
<gchristensen>
cool
sdier has joined #nixos-dev
kalbasit has joined #nixos-dev
alunduil has joined #nixos-dev
c00w has joined #nixos-dev
bhipple has quit [Ping timeout: 265 seconds]
aria has joined #nixos-dev
noonien has joined #nixos-dev
rajivr___ has joined #nixos-dev
jared-w has quit [Remote host closed the connection]
aristid has quit [Remote host closed the connection]
sorear has quit [Remote host closed the connection]
teozkr has quit [Remote host closed the connection]
vdemeester has quit [Remote host closed the connection]
aristid has joined #nixos-dev
teozkr has joined #nixos-dev
vdemeester has joined #nixos-dev
sorear has joined #nixos-dev
claudiii has quit [Read error: Connection reset by peer]
angerman has quit [Read error: Connection reset by peer]
emilazy has quit [Remote host closed the connection]
georgyo has quit [Remote host closed the connection]
jared-w has joined #nixos-dev
georgyo has joined #nixos-dev
angerman has joined #nixos-dev
emilazy has joined #nixos-dev
davidtwco has quit [Remote host closed the connection]
zimbatm has quit [Remote host closed the connection]
chrisaw has quit [Remote host closed the connection]
dmj` has quit [Remote host closed the connection]
thoughtpolice has quit [Remote host closed the connection]
scott has quit [Remote host closed the connection]
<genesis>
23 days of nixpkgs process, there is more patient boys , but imho we have a problem to delagate.
chrisaw has joined #nixos-dev
scott has joined #nixos-dev
<infinisil>
I think this is the third time I've seen this happen :(
<genesis>
only ? sorry i don't believe you, a year i work for nixpkgs, i saw that more.
<genesis>
then i answer to him, i really think this project suffer of the insider syndrom.
<genesis>
i'd workded so much on this never get credited, a 36 years old professional, i really think something is wrong , not for myself, but that illustrate the project
<genesis>
not able to recrut a foss proffessional, spending his full time on the projet, how can less implicated people would be
<gchristensen>
genesis: on your reply, please change "and @worldofpeace with his powerful" to "and @worldofpeace with their powerful" , and "reality, he suffers" to "reality, they suffers"
<genesis>
i imagine some people are "long life to nur" , that'd explain some no answer by people contributing there instead than on main stream.
<genesis>
sorry i don't speak well english, perhaps it would change the game anyway
<gchristensen>
genesis: it is okay, but worldofpeace is not a "he" or "him". worldofpeace is "they" and "them"
<genesis>
i don't know he's so much people same time, i don't understand your point here
<gchristensen>
I edited your comment for you -- you can see the way I meant
<genesis>
ho sorry gchristensen i think you get it ,and i don't want to offense anyone but make people realise.
<gchristensen>
I do understand, sometimes PRs take a long time
<gchristensen>
because they are complicated or not quite right
drakonis has quit [Ping timeout: 255 seconds]
<genesis>
i really try to improve thing .
<flokli>
It's a lot of PRs, and we don't have a good workflow on making sure things stay on track. some things might lay on the side for a while, either because the author is not getting back, or because the reviewer isn't getting back, or because of the lack of time on any of these sides.
<flokli>
gchristensen: how do I interpret these graphs?
<flokli>
nixpkgs has 1838 open PRs, this graph says it's around 180 currently.
<genesis>
i'm a floss professional with a hearth health issue, then i spent time when i strong enough and get no recruting since month i spent full day on that.
<genesis>
i describe dozen of issue that could be close, i fix dozen else, then no answen
<genesis>
so i don't thing the process is SO good.
<genesis>
s/thing/think
<worldofpeace>
Umm this situation has been enough to summon me 🤣 genesis It's exclusively they/them because I'm nonbinary. This PR would have been merged 6days ago but I basically don't have this as a priority (or time). I believe these RFCS implemented https://github.com/NixOS/rfcs/pull/50https://github.com/NixOS/rfcs/pull/30 would make people love interacting with NixOS more.
<worldofpeace>
It's prominent in the PR template that we basically have a PR problem, it hurts new contributors. I was lucky when I first started contributing to move through it.
<danderson>
it's kinda telling that both of those PRs are closed because the authors abandoned them :/
<worldofpeace>
Literally, nixpkgs being such a lot of work that 0050 couldn't be finished
<genesis>
just recrut ... what is the issue this recrutment here ?
<worldofpeace>
I've helped lots of people get commit bit. But that doesn't fix everything.
<danderson>
From reading through past proposals, the core problem seems to be trust. There's no way to grant safe permission to a subset of nixpkgs, or for a subset of changes
<genesis>
sure, that's called opensource
<danderson>
so people (e.g. me) have to get from "who is this" to "you can pwn nix" before they can make a significant dent.
<adisbladis>
Also (speaking from personal experience), when you get commit bit you're all excited and want to merge as many PRs as you can. But it gets tiring.
<danderson>
Right now what I can do is walk around open PRs, going "sure, that looks fine. But I can't leave review comments, or merge, so what's the point?"
<danderson>
I'm going to stop complaining now, it's unconstructive. I agree that RFC 30 and 50 would help a lot. What's the process for reopening them?
<genesis>
could i be able to find a missed whitespace to shine about it.
__monty__ has quit [Quit: leaving]
<danderson>
I want to persuade my coworkers to switch to NixOS in production, so I'm very interested in keeping nixpkgs healthy.
<genesis>
donno, i've not pb to commit to ubuntu when customer needs it.
<worldofpeace>
adisbladis: that's true, but I've found a balence of the greater responsibilty allowing me to collaborate with everyone in my own uniquely defined way. And hopefully leaving a trail people can follow. It seems to be working.
<adisbladis>
danderson: Do you have anything in particular that's not in a good state now that's stopping you from adopting it in production?
<danderson>
adisbladis: nixops isn't a good fit, so I have to figure out a custom deploy process, but that's fine. My main worry is "what about CVEs and updates?"
<danderson>
To reuse the comment on ubuntu: I have faith that Canonical merges CVE patches rapidly. I worry about them being lost in the nixpkgs PR pile
<adisbladis>
Right, that's completely fair.
<danderson>
(Canonical is also a corporation, etc., so obviously different)
<danderson>
that's why I want to try and help if I can, but I just have no idea where to start.
<flokli>
yeah, the security situation currently is a bit concerning. We have a bit of tooling to track issues (not perfect), some people doing PRs applying patches, but we don't have people dedicated to that (afaik)
<flokli>
danderson: a good start would be to join #nixos-security, go through the list of issues/PRs marked with security
<flokli>
there's vuln roundups happening in regular intervals.
<adisbladis>
danderson: Btw, what makes Nixops not a good fit?
<Profpatsch>
danderson: idk, you sound like a person who should have the commit bit
<danderson>
flokli: thanks for the pointer. What can I do about them, without commit access? That's what feels like the actual blocker. I can look at the scary list, but can't do anything abou them
<flokli>
danderson: you can file PRs fixing these
<flokli>
and drop links to them in that channel
<danderson>
ack.
<adisbladis>
danderson: You can make PRs (and po ping the security team)
<flokli>
so people can review them
<danderson>
adisbladis: main problems with nixops: secrets are deployed impermanently, so a random AWS reboot means the machine comes up broken; and the workflow is hostile to multi-operator setups due to the extra state stuff
<Profpatsch>
I had the idea of reviewing a random PR every day, but tbh I’m already 1 week behind my todo list as-is
<adisbladis>
danderson: Can I PM?
<danderson>
so far I've had good success with basic rsync+nixos-rebuild, so I'm not actually worried about nixops for production
<danderson>
sure.
<Profpatsch>
danderson: If possible, keep PRs small, big PRs usually won’t be reviewed because most people can’t spend more than 30 minutes at a time on OSS
<Profpatsch>
And it’s surprisingly easy to blow that budget