worldofpeace_ changed the topic of #nixos-dev to: #nixos-dev NixOS Development (#nixos for questions) | NixOS 20.03 BETA Announced | | | 19.09 RMs: disasm, sphalerite; 20.03: worldofpeace, disasm |
<infinisil> Regarding my original goal, I think I'll use /run/keys/${username} now
<infinisil> Though I'm not sure about the permissions for it
<infinisil> Say you have a secret declared as `user = "paul"; group = "users";`
<LnL> yeah making the permissions of the root correct works around the world readable issue, but it's a little brittle
<infinisil> This would get stored in /run/keys/paul/secret, with permissions 440, belonging to paul and group users
<infinisil> But what should the perms of /run/keys/paul be?
<infinisil> It can't be `chown paul:paulgroup` because then group `users` won't be able to access the secret, unless /run/keys/paul is also 555 or so
<infinisil> Which then defeats the purpose of having per-user secret stores
<infinisil> xattrs could be used probably, but I'd rather not
<infinisil> If it can be avoided
<LnL> the current /run/keys approach doesn't solve that either
<infinisil> Yeah, I'm trying to improve on that
drakonis has joined #nixos-dev
<infinisil> Maybe /run/keys/per-user/${username} and /run/keys/per-group/${groupname}
<infinisil> That might work nicely
<LnL> that makes sense
<infinisil> (btw I'll use /run/secrets for my tool to not conflict with anything from NixOS/nixops)
<gchristensen> how about /run/nixoses-secrets/
<infinisil> Yeah maybe that's better
<infinisil> (or whatever the project will be named)
<gchristensen> or full java, com.github.infinisil.nixoses
<infinisil> Hehe
<gchristensen> .$(uuidgen)
<LnL> hrm why does nix-build want to access profiles?
<gchristensen> hm. channels?
<gchristensen> hm
<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> ` = "user"` and ` = "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.
<infinisil> nix#8
<{^_^}> (by edolstra, 7 years ago, open): Support private files in the Nix store
<infinisil> That would be great
<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
<infinisil> security.acme.certs.<name>.allowKeysForGroup
<infinisil> Not exactly
drakonis has joined #nixos-dev
<infinisil> But there's a user and group setting, and allowKeysForGroup which is false by default
<infinisil> Turning that on makes the secret "belong to the group"
<infinisil> Off being "belongs to the user"
<infinisil> It might be possible to get rid of the allowKeysForGroup by making the user/group setting mutually exclusive
<infinisil> s/by/option by
bhipple has joined #nixos-dev
Synthetica has quit [Quit: Connection closed for inactivity]
orivej has quit [Ping timeout: 258 seconds]
lovesegfault has joined #nixos-dev
<clever> error: experimental Nix feature 'ca-references' is disabled
<clever> thats a new one
abathur has quit [Ping timeout: 255 seconds]
<clever> the receiving end gives that error
<drakonis> ca-references is the flag for content addressed store contents?
<clever> drakonis: its entirely breaking the ability to nix-copy-closure a .drv file
<drakonis> hm.
<clever> gchristensen: you got any idea? its blocking usage of the aarch64 community box
justanotheruser has quit [Read error: Connection reset by peer]
<{^_^}> firing: RootPartitionLowDiskSpace:
lovesegfault has quit [Quit: WeeChat 2.7.1]
justanotheruser has joined #nixos-dev
justan0theruser has joined #nixos-dev
justanotheruser has quit [Ping timeout: 240 seconds]
drakonis has quit [Ping timeout: 240 seconds]
lovesegfault has joined #nixos-dev
bhipple has quit [Remote host closed the connection]
abathur has joined #nixos-dev
abathur has quit [Ping timeout: 265 seconds]
orivej has joined #nixos-dev
cole-h has quit [Ping timeout: 265 seconds]
<{^_^}> firing: RootPartitionLowDiskSpace:
Jackneill has joined #nixos-dev
ris has quit [Ping timeout: 260 seconds]
sdier has quit [Ping timeout: 260 seconds]
__monty__ has joined #nixos-dev
phreedom has quit [Ping timeout: 240 seconds]
sdier has joined #nixos-dev
ryantm has quit [Ping timeout: 265 seconds]
ryantm has joined #nixos-dev
phreedom has joined #nixos-dev
lovesegfault has quit [Quit: WeeChat 2.7.1]
lovesegfault has joined #nixos-dev
lovesegfault has quit [Quit: WeeChat 2.7.1]
lovesegfault has joined #nixos-dev
orivej has quit [Ping timeout: 256 seconds]
orivej has joined #nixos-dev
<zimbatm> !!! the nixos homepage has changed hosting to netlify !!!
<zimbatm> this might break things like the nix installer if they don't follow redirects
sogatori has joined #nixos-dev
<LnL> somebody ran into an ssl error on
<niksnut> works fine here
<LnL> yeah same for me
<gchristensen> niksnut, garbas: used to work -- can we bring those URLs back online?
<gchristensen> ^ is currently breaking all Travis builds
<gchristensen> (and of course, all the versions that used to be there)
<andi-> zimbatm: yay, so it is now at google? (According to whois) Still (means) no IPv6? :'(
<niksnut> netlify
masaeedu[m] has joined #nixos-dev
<niksnut> gchristensen: looks like a permission problem
<LnL> they can't reproduce anymore so whatever it was it's fine now
<{^_^}> firing: RootPartitionLowDiskSpace:
<gchristensen> niksnut: are you or garbas on fixing that?
sogatori has quit [Remote host closed the connection]
<andi->, (after redirect) just displays: Error: [object Object] :/
<zimbatm> andi-: there is one blog post that says that netlify supports IPv6. It's probably just a matter of adding those AAAA DNS entries
<niksnut> they don't provide AAAA entries
<adisbladis> The redirect is a 301
<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.
* andi- searches for the docs again
<zimbatm> garbas: how about recording all the issues and rollback the DNS change for now?
<andi-> I am pretty sure I copied that from some docs back then... Might have been changed since then :/
orivej has quit [Ping timeout: 258 seconds]
orivej has joined #nixos-dev
* garbas is back online
<garbas> zimbatm: dns was reverted
* garbas looks through the issues to create PR with fixes
abathur has joined #nixos-dev
abathur has quit [Ping timeout: 240 seconds]
drakonis has joined #nixos-dev
Jackneill has quit [Ping timeout: 256 seconds]
Jackneill has joined #nixos-dev
genesis has quit [Remote host closed the connection]
Jackneill has quit [Read error: Connection reset by peer]
Jackneill has joined #nixos-dev
b42 has joined #nixos-dev
teto has joined #nixos-dev
<{^_^}> firing: RootPartitionLowDiskSpace:
cole-h has joined #nixos-dev
<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)
<{^_^}> #82006 (by emilazy, 3 days ago, open): linuxPackages_{,_latest,_testing}_hardened: enable 32-bit emulation
lovesegfault has quit [Ping timeout: 240 seconds]
lovesegfault has joined #nixos-dev
genesis has joined #nixos-dev
<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]
<{^_^}> firing: RootPartitionLowDiskSpace:
teto has quit [Quit: WeeChat 2.7.1]
lovesegfault has quit [Quit: WeeChat 2.7.1]
bhipple has joined #nixos-dev
claudiii has joined #nixos-dev
<gchristensen> Profpatsch: can you take a look at my travis log folding code to see if you see why its busted?
bhipple has quit [Ping timeout: 260 seconds]
bhipple has joined #nixos-dev
lovesegfault has joined #nixos-dev
drakonis has quit [Quit: WeeChat 2.7.1]
<lovesegfault> zimbatm: does folding@home support gpus?
ixxie has joined #nixos-dev
<lassulus> there is something mentioned about gpus in the discource article so I would guess yes
<lovesegfault> Nice, I'm putting this box to fold:
<Profpatsch> gchristensen: which one?
<gchristensen> Profpatsch: it doesn't ... fold :)
Jackneill has joined #nixos-dev
Jackneill has quit [Client Quit]
<Profpatsch> gchristensen: did we ever get the folds on lorri working? I can’t remember
<gchristensen> not sure :P
<lovesegfault> Is there any compelling reason to use Travis now that there is GH actions?
<Profpatsch> gchristensen: this might work:
<gchristensen> lovesegfault: the compelling reason for me is it works and uses travis, and I've never used GH actions :P
<Profpatsch> but yeah, insert *abandon sinking ship* meme here
* Profpatsch has no idea about GH actions
<lovesegfault> gchristensen, Profpatsch check this out:
<lovesegfault> it generates GH actions jobs for each of my machines automagically
<gchristensen> lovesegfault: want to send me a PR using GH actions?
<lovesegfault> gchristensen: can do
<Profpatsch> lovesegfault++
<{^_^}> lovesegfault's karma got increased to 20
<lovesegfault> ci looks like this in the end:
<Profpatsch> gchristensen: guess we could enable that for lorri? Or does it require extended admin foo permissions?
<gchristensen> Profpatsch: I wouldn't :x
drakonis has joined #nixos-dev
<Profpatsch> let’s see when travis folds (not talkin bout the logs)
<gchristensen> lol
<Profpatsch> lol, they have a gui where you can literally paste yaml snippets from the sidebar. lego, but it’s ci workflows now
<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]
claudiii has joined #nixos-dev
zimbatm has joined #nixos-dev
thoughtpolice has joined #nixos-dev
dmj` has joined #nixos-dev
davidtwco has joined #nixos-dev
<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> i get #75392, #81098 ... stucks by worldofpeace since he started to review then nothing
<{^_^}> (by bignaux, 13 weeks ago, open): soulseekqt: fix icons, change unpack method, update homepage, more generic appimage handling
<{^_^}> (by bignaux, 2 weeks ago, open): cadence: fix dbus,libjack and missing dependancies
<gchristensen> genesis: worldofpeace is not a he
<genesis> what the difference ?
<gchristensen> s/he/they/ s/his/their/ s/him/them/
<gchristensen> he is masculine, they is not
<genesis> how should i know ?
<gchristensen> well, because I'm telling you :)
<gchristensen> it is okay to make the mistake, it is why I am telling you -- to avoid future mistakes like that for worldofpeace
<Profpatsch> I don’t understand why the PR was closed, it seems to have gotten an awesome review?
<Profpatsch> And pretty much ready for merge.
<genesis> oki, i guess that's good so, i'd not like he was a white man.
<gchristensen> because they did not want to maintain it, and the author chose to close it
<gchristensen> genesis: :)
<genesis> ( i guess that's the meaning of all that ...)
andi- has joined #nixos-dev
<genesis> Profpatsch : anyway i spent time to review bqv , and much time to try to make this easily to commit in nixpkgs
<genesis> see #81833 then #82158 and more
<{^_^}> (by bignaux, 6 days ago, merged): appimage-run: unify appimageTools and appimage-run
<{^_^}> (by bignaux, 2 days ago, open): [wip] top-level: add appimage-packages.nix
<genesis> this was really enough to merge, i don't understand why we're not able to accept other people stuff when they are not insiders.
<gchristensen> how many insiders does Nixpkgs have?
<flokli> genesis: I merged #75392 because I stumbled over it. Maybe simply do a friendly ping inside the PR, or here if things seem to stall?
<{^_^}> (by bignaux, 13 weeks ago, merged): soulseekqt: fix icons, change unpack method, update homepage, more generic appimage handling
<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 would make people love interacting with NixOS more.
<{^_^}> rfcs#50 (by FRidh, 29 weeks ago, closed): [RFC 0050] Merge bot for maintainers
<{^_^}> rfcs#30 (by timokau, 1 year ago, closed): [RFC 0030] Formalize review workflow
<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.
<{^_^}> firing: RootPartitionLowDiskSpace:
<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