justanotheruser has quit [Ping timeout: 252 seconds]
orivej has joined #nixos-dev
drakonis has quit [Read error: No route to host]
drakonis_ has joined #nixos-dev
edwtjo has joined #nixos-dev
edwtjo has joined #nixos-dev
drakonis_ has quit [Ping timeout: 252 seconds]
drakonis_ has joined #nixos-dev
orivej has quit [Ping timeout: 260 seconds]
orivej has joined #nixos-dev
drakonis_ has quit [Read error: Connection reset by peer]
drakonis has joined #nixos-dev
drakonis has quit [Read error: Connection reset by peer]
drakonis has joined #nixos-dev
emilazy has joined #nixos-dev
emilazy has quit [Changing host]
emily has quit [Changing host]
emily has joined #nixos-dev
arcnmx has joined #nixos-dev
arcnmx has quit [Changing host]
drakonis has quit [Read error: Connection reset by peer]
drakonis_ has joined #nixos-dev
abathur has joined #nixos-dev
drakonis_ has quit [Read error: Connection reset by peer]
drakonis_ has joined #nixos-dev
drakonis has joined #nixos-dev
drakonis1 has joined #nixos-dev
drakonis_ has quit [Read error: Connection reset by peer]
drakonis has quit [Ping timeout: 240 seconds]
drakonis has joined #nixos-dev
drakonis1 has quit [Read error: Connection reset by peer]
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 quit [Ping timeout: 240 seconds]
lopsided98 has quit [Remote host closed the connection]
lopsided98 has joined #nixos-dev
asymmetric has quit [Ping timeout: 260 seconds]
puck has quit [Ping timeout: 260 seconds]
asymmetric has joined #nixos-dev
dongcarl8 has joined #nixos-dev
puck has joined #nixos-dev
multun has quit [Ping timeout: 260 seconds]
dongcarl has quit [Ping timeout: 260 seconds]
Cale has quit [Ping timeout: 260 seconds]
samueldr has quit [Ping timeout: 260 seconds]
dmj` has quit [Ping timeout: 260 seconds]
kcalvinalvin has quit [Ping timeout: 260 seconds]
dongcarl8 is now known as dongcarl
dmj` has joined #nixos-dev
samueldr has joined #nixos-dev
Cale has joined #nixos-dev
kcalvinalvin has joined #nixos-dev
multun has joined #nixos-dev
drakonis_ has quit [Read error: Connection reset by peer]
drakonis_ has joined #nixos-dev
LnL has joined #nixos-dev
LnL has joined #nixos-dev
LnL has quit [Changing host]
drakonis_ has quit [Read error: Connection reset by peer]
drakonis_ has joined #nixos-dev
bhipple has joined #nixos-dev
drakonis has joined #nixos-dev
drakonis1 has joined #nixos-dev
drakonis_ has quit [Ping timeout: 252 seconds]
drakonis_ has joined #nixos-dev
drakonis1 has quit [Ping timeout: 255 seconds]
drakonis has quit [Ping timeout: 255 seconds]
drakonis has joined #nixos-dev
drakonis has quit [Client Quit]
drakonis has joined #nixos-dev
lovesegfault has joined #nixos-dev
onixie has joined #nixos-dev
drakonis has quit [Quit: WeeChat 2.6]
lovesegfault has quit [Ping timeout: 240 seconds]
lovesegfault has joined #nixos-dev
drakonis has joined #nixos-dev
bhipple has quit [Remote host closed the connection]
drakonis_ has quit [Read error: Connection reset by peer]
drakonis_ has joined #nixos-dev
drakonis_ has quit [Read error: Connection reset by peer]
drakonis_ has joined #nixos-dev
drakonis has quit [Ping timeout: 265 seconds]
octe has quit [Ping timeout: 268 seconds]
abathur has quit [Ping timeout: 252 seconds]
orivej has quit [Ping timeout: 272 seconds]
lovesegfault has quit [Quit: WeeChat 2.7.1]
drakonis_ has quit [Read error: Connection reset by peer]
drakonis has joined #nixos-dev
drakonis has quit [Read error: Connection reset by peer]
drakonis has joined #nixos-dev
cole-h has quit [Ping timeout: 240 seconds]
drakonis has quit [Ping timeout: 240 seconds]
__monty__ has joined #nixos-dev
ris has quit [Ping timeout: 258 seconds]
abathur has joined #nixos-dev
abathur has quit [Ping timeout: 260 seconds]
tazjin has quit [Excess Flood]
tazjin has joined #nixos-dev
octe has joined #nixos-dev
FRidh has quit [Quit: Konversation terminated!]
FRidh has joined #nixos-dev
orivej has joined #nixos-dev
Jackneill has joined #nixos-dev
psyanticy has joined #nixos-dev
drakonis has joined #nixos-dev
drakonis has quit [Read error: Connection reset by peer]
drakonis_ has joined #nixos-dev
<domenkozar[m]>
gchristensen: any objection to being able to set number of build users to create on macos?
<gchristensen>
in the installer?
<gchristensen>
is there a need for it to be higher than 32?
<domenkozar[m]>
yup
<gchristensen>
tell me more? :P
<domenkozar[m]>
on github actions
<domenkozar[m]>
it takes 1-2s to create one user
<gchristensen>
slow
<domenkozar[m]>
making nix installation take ~90s
<domenkozar[m]>
since it wants to create 32 users for 2 core machine
<gchristensen>
aye. it used to be capped at the number of processors automatically, and for some reason was made to just 32
<gchristensen>
how do you propose setting it?
<domenkozar[m]>
capping to number of processors as a default is very sensible to me
<domenkozar[m]>
any good reason that was changed?
<gchristensen>
I believe so, looking in to it
<domenkozar[m]>
<3
<gchristensen>
the issue is users were passing a higher `-j` than their system has cores
<domenkozar[m]>
is there ever a good reason?
<domenkozar[m]>
I guess for the substituter it is
<gchristensen>
and the resulting error was " error: all build users are currently in use; consider creating additional users and adding them to the ‘nixbld’ group". maybe a "try a lower -j" or even "automatically capping max-jobs to number-of-build-users"
<domenkozar[m]>
which should be
<domenkozar[m]>
warning: waiting available build slot
<domenkozar[m]>
for*
<clever>
gchristensen: what about when i have build machines, i want it to spawn more jobs, just not locally
<gchristensen>
clever: I don't know! :)
<domenkozar[m]>
gchristensen: ok, I'm fine if we just allow installer to respect NIX_CORES=4
drakonis_ has quit [Ping timeout: 258 seconds]
<domenkozar[m]>
or NIX_INSTALLER
<domenkozar[m]>
whatever is the convention
<gchristensen>
domenkozar[m]: at any rate, I think being able to specify the number is a good idea, nproc isn't necessarily the right solution, nor is 32. I always feel petrified merging PRs to the installer beacuse of ... well, you know. so something which is obviously right but not lazily right would be nice :)
<domenkozar[m]>
this should be real simple
<domenkozar[m]>
another change I'd like to make is
<domenkozar[m]>
currently I need to write nix.conf
<domenkozar[m]>
to avoid the curl segfault and set some sane default for installer
<domenkozar[m]>
then installer complains for existing installation
<domenkozar[m]>
ok, I can avoid that with magic env var
<gchristensen>
one sec
<domenkozar[m]>
but then I need to overwrite installed nix.conf
<domenkozar[m]>
and restart nix-daemon
<domenkozar[m]>
my proposal is to be able tell installer to just use existing nix.conf
<domenkozar[m]>
(this is multi-user install obviously)
<gchristensen>
annoying -- the magic env var isn't using a convention, just ALLOW_PREEXISTING_INSTALLATION. I don't think it is a good idea to just use the existing ni.econf
<gchristensen>
hi yes I can type
<domenkozar[m]>
I'd add something like ALLOW_PREEXISTING_NIXCONF
<domenkozar[m]>
or USE_PREEXISTING_NIXCONF
<gchristensen>
I'm not sure about that. let's focus on one thing at a time -- the nix user count
<zimbatm>
domenkozar[m]: I think you want to pass a custom nix.conf to the installer actually
<zimbatm>
which is the same but different :p
<domenkozar[m]>
maybe I should just populate user nix.conf :D
<domenkozar[m]>
ah can't set some settings there iirc
<domenkozar[m]>
right since I need to make user trusted among other things
<domenkozar[m]>
zimbatm: why is that better?
<domenkozar[m]>
or how
<gchristensen>
domenkozar[m]: I think changing: readonly NIX_USER_COUNT="32" to readonly NIX_USER_COUNT=${NIX_USER_COUNT:-32} would be fine
<zimbatm>
domenkozar[m]: because it's your intent. you want to install nix with a given nix.conf
<gchristensen>
I would prefer to not have the user replace the default nix.conf
<zimbatm>
right now you setup the nix.conf, then have to pretend nix was already installed by setting ALLOW_PREEXISTING_INSTALLATION=1
<domenkozar[m]>
and then also it overrides it :D
<gchristensen>
it is possible the installer will write important data in to the nix.conf which you might make go away unknowningly
<zimbatm>
if you could specify USE_CUSTOM_NIX_CONF=/path/to/conf then the installer could still fail in case a nix installation already exists
<gchristensen>
and I think there is a better way
<gchristensen>
I feel you're trying to run towards the simplest solution as fast as possible :/
<domenkozar[m]>
like always - but I'm all ears for a better solution
<zimbatm>
the only reason why you need to pre-empt the nix.conf is because of the segfault during channel update right?
<domenkozar[m]>
I also need to add trusted user
<zimbatm>
can't that be done after the install?
<domenkozar[m]>
and max-jobs to sane default, but that has little effect on the installer
<domenkozar[m]>
it can, but then you need to restart nix-daaemon
<domenkozar[m]>
which takes wooping 10s on macos
tazjin has quit [Excess Flood]
<zimbatm>
maybe we need something like ansible to install nix :p
<domenkozar[m]>
or just fix this problem with a 1 line fix :p
<domenkozar[m]>
gchristensen: what's the better way?
<zimbatm>
let's rewrite everything! :p
<gchristensen>
looking in to it!
tazjin has joined #nixos-dev
<domenkozar[m]>
ah ok, thanks :)
<zimbatm>
btw, it would be cool if channel updates could be turned off
<zimbatm>
if all your dependencies are pinned it's a waste of time
drakonis_ has joined #nixos-dev
<gchristensen>
domenkozar[m]: what if you could provide an additional nix.conf to be included?
<domenkozar[m]>
yeah
<domenkozar[m]>
however I wanted to leave that for another day
<gchristensen>
oh? why?
<domenkozar[m]>
that was answer to zimb
<gchristensen>
ah
<domenkozar[m]>
zimbatm*
<domenkozar[m]>
gchristensen: appending the config would also work
<domenkozar[m]>
although that can also break things, although impact is smaller
<gchristensen>
do you not like the idea of including the config?
<domenkozar[m]>
I think to do this proper, Nix would have to do the default things by itself
<gchristensen>
write it to /etc/cachix.conf, then ask the installer to include /etc/cachix.conf, and the installer would then output "include /etc/cachix.conf"
<domenkozar[m]>
installation shouldn't need to write the config, that goes against the idea
<gchristensen>
the default things?
<domenkozar[m]>
whatever installer needs to put into nix.conf
<gchristensen>
I have a feeling we're talking past each other :P
<domenkozar[m]>
I'm not sure, you said you'd like to do this proper, so that got me thinking that the proper way is that installer should use default nix.conf
<gchristensen>
right, so what I'm proposing is `NIX_EXTRA_CONFIG_FILE=/etc/cachix.conf run-nix-installer` and then having that variable being present causing the Nix installer to output "include $NIX_EXTRA_CONFIG_FILE" in the nix.conf at installation time
<domenkozar[m]>
as an empty file
<domenkozar[m]>
gchristensen: but do you need that if nix.conf is empty by default?
<gchristensen>
you mean the right thing is for Nix to just not need a nix.conf?
<domenkozar[m]>
for Nix to have sane defaults that otherwise installer would set
<domenkozar[m]>
to the code that configures nix.conf should rather be in Nix itsefl
<domenkozar[m]>
itself*
<domenkozar[m]>
so the code*
<domenkozar[m]>
blah, can't type.
<gchristensen>
I don't think we are going to get away from specifying build-users-group
<gchristensen>
at any rate, I think this include option is a good one -- and enables other use cases, too, and even having a NIX_EXTRA_CONFIG_FILES which IFS=" " separated would be great
<LnL>
yeah, the build users are only reason for nix.conf in the installer AFAIK
<gchristensen>
I think allowing tools like yours to hook in unintrusively like this is a good thing, too
<domenkozar[m]>
wouldn't it be better if Nix would first check if nixbld group and use that before defaulting to uids?
<domenkozar[m]>
nixbld group exists*
<gchristensen>
to clarify you're asking about a third topic?
<domenkozar[m]>
still the same - eliminating installers' need to write nix.conf
<gchristensen>
UID isn't related, it is just the group name
<gchristensen>
there are severe consequences for wrongly guessing the build group name
<domenkozar[m]>
it fallbacks to uid if group is not specified
<LnL>
it doesn't fall back AFAIK
<gchristensen>
I don't think it falls back
<domenkozar[m]>
runs if NIX_REMOTE is daemon). Obviously, this should not be used in multi-user settings with untrusted users.
<domenkozar[m]>
If the build users group is empty, builds will be performed under the uid of the Nix process (that is, the uid of the caller if NIX_REMOTE is empty, the uid under which the Nix daemon
<emily>
-1 for implicitly guessing groups
<emily>
nix is meant to be about implicit dependencies and objcap, c'mon :)
<emily>
er, explicit
<emily>
freudian slip...
<gchristensen>
right, it just runs the build as you
<LnL>
and nix will refuse to run the builder if it's started as root
<gchristensen>
that is the single-user build mode
<LnL>
(there's still a bug with that btw)
<gchristensen>
at any rate, I've gotta run -- I'd love to see a PR for the configurable user count, and possibly further discussion on the nix.conf instal-time customisation
<domenkozar[m]>
emily: it's about convention vs configuration
<domenkozar[m]>
and Nix already automatically fallbacks to single user mode
<domenkozar[m]>
so there's about the same magic as now :)
<domenkozar[m]>
like if you restart nix-daemon, it will just use single user mode while it's gone
<gchristensen>
(falling back to singe-user mode is safe, since it can't write to the multi-user store or kill other user's processes, and can only write to /nix/store if the store was configured as that user. unless the user running nix-build is root, in which case Nix will refuse to run until you've configured build-users-group)
<domenkozar[m]>
great, so what's the downside for checking for multi-user with nixbld group as default?
<LnL>
same problem as users.users."me".groups = [ "nixbld" ];
<domenkozar[m]>
LnL: not sure I follow :)
<LnL>
if you do that and run a build nix will kill all of your processes
<domenkozar[m]>
makes sense, why is then having a convention for nix group a bad thing? :)
<niksnut>
ideally we would get rid of nixbld, the only reason it exists is to allows non-chroot builders to create paths in the nix store
<niksnut>
but that could also be done using ACLs
<domenkozar[m]>
great! :)
<domenkozar[m]>
that would be so great.
<niksnut>
there is a branch somewhere that allocates UIDs automatically from some range
<niksnut>
unfortunately there is no standard for what range is safe to use
<gchristensen>
that'll be perfect once macOS 10.16 comes out and we can't run Nix anymore
<niksnut>
right :-)
<domenkozar[m]>
so it would kill three flies in one go!
<domenkozar[m]>
(sorry, slovenian version of the birds and stones)
<domenkozar[m]>
niksnut: so we'd need to allow specifying range?
evanjs has joined #nixos-dev
<domenkozar[m]>
gchristensen: thanks for the feedback, will create PR for user count
vcunat has joined #nixos-dev
<ma27[m]>
(same in german btw :p)
<domenkozar[m]>
niksnut: since you're here, I have another question :) Right now Nix will barf if there's a substitution missing for a dependency with "don't know how to build those paths". Do you think it would make sense to rather ignore all those substitutions?
<gchristensen>
Nix considers it an invariant that a cache has the complete closure for every closure it contains
<domenkozar[m]>
which makes sense, I'm only asking that instead of erroring out it would be ignoring the closure
<gchristensen>
ah
<domenkozar[m]>
the invariant still holds that way.
<vcunat>
It might sense to break this invariant for some "overlay" caches where people rely e.g. on cache.nixos.org for almost everything except for a small add-on part.
<vcunat>
But perhaps noone cares for such use cases (for now).
abathur has joined #nixos-dev
<domenkozar[m]>
(sorry for a storm of issues, just came back from vacations)
<gchristensen>
hehehe
<domenkozar[m]>
I can do per partes :P
<gchristensen>
it might be good to see that problem and ignore that cache for that closure -- to be more resilient against upstream error
<domenkozar[m]>
what I'm proposing is if you have closure A -> B -> C
<domenkozar[m]>
and B is missing, it would substitute A but build B and C
abathur has quit [Ping timeout: 265 seconds]
<domenkozar[m]>
which makes debugging cache issues a bit trickier, that's the downside
<gchristensen>
where you're nix-build'ing `C`, or `A`?
<domenkozar[m]>
C
<gchristensen>
so in this case Nix has asked for C, the cache said yep, I've got C. then Nix asked for B, and the cache said I don't have B. then you want Nix to ask for A, get A, then build B and C?
<domenkozar[m]>
exactly.
drakonis_ has quit [Ping timeout: 255 seconds]
<domenkozar[m]>
for debugging purposes it would be good to print a warning in this case, but I'm mainly interested to get rid of erroring out
<gchristensen>
interesting
<domenkozar[m]>
the reason is that cachix doesn't upload in topological order, which makes it able to not limit parallelism
<domenkozar[m]>
the downside I'd have to check invariant on each narfile retrieval, but I think this better be addressed in Nix
drakonis_ has joined #nixos-dev
<niksnut>
domenkozar[m]: yes
<domenkozar[m]>
(since Nix is checking the invariant anyway, it's just a matter of handling it)
drakonis has joined #nixos-dev
<domenkozar[m]>
niksnut: great :)
<domenkozar[m]>
I'll stop for today since I can't type, can't think after 4 flights :)
<domenkozar[m]>
thanks for feedback y'all :)
<gchristensen>
go sleep haha
drakonis_ has quit [Ping timeout: 260 seconds]
<domenkozar[m]>
trying really hard to get into my timezone
<clever>
yorick: have you seen narfuse and fusenar?
<domenkozar[m]>
yorick: why do you need distributed cache? :)
<__monty__>
yorick: Weren't they always pretty much the same project? One built on top of the other?
<niksnut>
and 'nix mount'
<__monty__>
domenkozar[m]: Fault tolerance? Ease of setup? Sheer amount of evaluation power?
<__monty__>
Less reliance on trust if it incorporates affirming a build is correct.
<__monty__>
I.e., if 10 people confirm a certain build's hash in a PoW-ey scheme you don't have to trust any one of them 100%.
<domenkozar[m]>
I think that's quite tricky, it seems appealing from blockchain but hard to get right
<domenkozar[m]>
I think trust is not the problem you have, but that's subjective
<domenkozar[m]>
and depends on your threat model anyway
<domenkozar[m]>
keeping signing key secrets gets you quite far
<domenkozar[m]>
secret*
<clever>
the first layer of the problem, is mapping a $out to the narhash of $out
<clever>
which needs some kind of central db or index, but you could reuse the narinfo files as-is
drakonis has quit [Read error: Connection reset by peer]
<clever>
the 2nd layer, is fetching a .nar, once you know its hash, in the case of ipfs and its merkle hashing, you would have to add the ipfs hash to the .narinfo
drakonis has joined #nixos-dev
<vcunat>
The trust problem seems mostly independent of the "CDN problem".
<clever>
and trust can be solved by just using the existing narinfo files, and you can just use a normal binary cache as the seed to feed the cloud
<vcunat>
Yes, they already do have signatures.
<clever>
yep
<vcunat>
At least for me, manually selecting trusted builders is enough.
tazjin has quit [Read error: Connection reset by peer]
<gchristensen>
the 404 issue is a significant challenge I think
tazjin has joined #nixos-dev
drakonis has quit [Read error: Connection reset by peer]
drakonis_ has joined #nixos-dev
drakonis_ has quit [Read error: Connection reset by peer]
drakonis has joined #nixos-dev
<__monty__>
The trust problem is more this. If you decide to trust a specific key you're vulnerable to that key getting compromised. If you decide to rely on some PoW (which can only really work with 100% reproducible builds) many keys need to be compromised before you're at risk.
<vcunat>
I personally don't believe in PoW schemes for this purpose.
<vcunat>
And even generally they seem rather problematic.
<gchristensen>
not to mention having a build output isn't proof of work
<__monty__>
It's not enough, no.
<__monty__>
But less of the work is wasted than in cryptocurrencies.
<vcunat>
I assumed each signature would contain some additional proof "useless" work.
drakonis has quit [Read error: Connection reset by peer]
<__monty__>
vcunat: The proof'd very much be a proof of building the thing.
drakonis has joined #nixos-dev
<gchristensen>
having the thing doesn't mean you built it
<__monty__>
That's why I said it's not enough. I never claimed the hash of the build result would be a PoW.
<gchristensen>
ah.
<__monty__>
That was the first spark that started me down this thought experiment though. "Reproducible builds, hmm you could check whether you attain the same hash, hmm that's not enough to prove to someone else cause you could just fetch the cached result and hash that..."
<__monty__>
I haven't worked out a PoW though, not even a concept. I just hand wavingly assume it wouldn't be all that hard to come up with.
<__monty__>
If zero-knowledge proofs are a thing proofs of useful work can't be impossible.
<vcunat>
I'm not sure it's necessarily possible. The build output of the build is necessarily public.
<vcunat>
(say, you can download it from some other party who did the build)
<NinjaTrappeur>
keep in mind nixpkgs is not 100% reproductible. Is this discussion belonging to #nixos-chat ?
<clever>
__monty__: yeah, even with Reproducible builds, i could just build a backdoor'd version, and then post to the records claiming i'm 50 different people, and we all produced hash X when building it
<clever>
__monty__: until 51 other people build the real source, and can proove their version is more "correct"
<gchristensen>
or more likely just put in their more favored cryptominer
<clever>
yeah, thats where a PoW scheme would come into play
<clever>
to stop you from just claiming to be 50 different people, and spamming the system
<gchristensen>
I'm not sure it is very useful anyway since mismatched hashes are a natural and default property of the system
<clever>
one variant of PoW ive seen, is basically just pub/priv key signing as the PoW algo, and the signature must have N 0's at the start
<clever>
the strenght that system had, is its pool resistant, if you can do the hashing work, you can spend the rewards, so you cant share the work with untrusted peers
abathur has quit [Read error: Connection reset by peer]
drakonis_ has joined #nixos-dev
abathur has joined #nixos-dev
justanotheruser has quit [Ping timeout: 255 seconds]
drakonis has quit [Ping timeout: 272 seconds]
drakonis has joined #nixos-dev
drakonis_ has quit [Ping timeout: 265 seconds]
abathur has quit [Read error: Connection reset by peer]
abathur has joined #nixos-dev
abathur has quit [Read error: Connection reset by peer]
justanotheruser has joined #nixos-dev
<__monty__>
clever: It'd complicate pool design but it doesn't prevent it completely.
<clever>
__monty__: it would require you to hand your private key out to every hashing peer, or for you to send that peer several gig/second of pre-computed data
<clever>
the 1st means that peer can just run off with the block reward, the 2nd wouldnt be feasible to scale
<__monty__>
You could do forced profit sharing.
drakonis has quit [Ping timeout: 240 seconds]
justanotheruser has quit [Ping timeout: 272 seconds]
abathur has joined #nixos-dev
abathur has quit [Read error: Connection reset by peer]
orivej has joined #nixos-dev
abathur has joined #nixos-dev
abathur has quit [Read error: Connection reset by peer]
drakonis has joined #nixos-dev
myskran has joined #nixos-dev
myskran has quit [Read error: Connection reset by peer]
myskran has joined #nixos-dev
myskran has quit [Read error: Connection reset by peer]
infinisil has quit [Quit: Configuring ZNC, sorry for the joins/quits!]
vcunat has quit [Quit: Leaving.]
infinisil has joined #nixos-dev
ris has joined #nixos-dev
justanotheruser has joined #nixos-dev
drakonis_ has joined #nixos-dev
ixxie has quit [Ping timeout: 258 seconds]
drakonis_ has quit [Read error: Connection reset by peer]
drakonis_ has joined #nixos-dev
psyanticy has quit [Quit: Connection closed for inactivity]
drakonis has quit [Read error: Connection reset by peer]
justanotheruser has quit [Read error: Connection reset by peer]
drakonis2 has joined #nixos-dev
drakonis_ has quit [Ping timeout: 258 seconds]
drakonis_ has joined #nixos-dev
drakonis2 has quit [Ping timeout: 272 seconds]
justanotheruser has joined #nixos-dev
justanotheruser has quit [Ping timeout: 240 seconds]
infinisil has quit [Quit: Configuring ZNC, sorry for the joins/quits!]
infinisil has joined #nixos-dev
<LnL>
there's no way to check if someone is eligible before sending the invite right?
zarel_ has joined #nixos-dev
zarel has quit [Ping timeout: 252 seconds]
infinisil has quit [Quit: Configuring ZNC, sorry for the joins/quits!]
infinisil has joined #nixos-dev
infinisil has quit [Remote host closed the connection]
infinisil has joined #nixos-dev
infinisil has quit [Quit: Configuring ZNC, sorry for the joins/quits!]
infinisil has joined #nixos-dev
infinisil has quit [Remote host closed the connection]
infinisil has joined #nixos-dev
infinisil has quit [Quit: Configuring ZNC, sorry for the joins/quits!]
infinisil has joined #nixos-dev
infinisil has quit [Remote host closed the connection]
infinisil has joined #nixos-dev
infinisil has quit [Client Quit]
infinisil has joined #nixos-dev
justanotheruser has joined #nixos-dev
<infinisil>
I added #80952 as a blocker to the 20.03 milestone because it seems like without it TLSv1.2 doesn't work at all in nginx (which it should still be)
<infinisil>
People who run unstable nixpkgs and nginx with SSL: Can you test to see if `openssl s_client -connect <domain>:443 -tls1_2` works for you or if it throws a handshake error?
genesis has quit [Remote host closed the connection]
__monty__ has quit [Quit: leaving]
rajivr___ has quit [Quit: Connection closed for inactivity]
tilpner has quit [Ping timeout: 258 seconds]
tilpner_ has joined #nixos-dev
rajivr___ has joined #nixos-dev
<emily>
infinisil: wfm (but then I set my own ciphers list)
<emily>
(so probably irrelevant)
<emily>
infinisil: I don't think severity: security is appropriate for that bug as it's more like things being too secure rather than not secure enough, fwiw
<emily>
(but I do agree it's a bad regression)
<infinisil>
Hm, it's related to security at least
<infinisil>
emily: I sure would like to know where it comes from
<emily>
my interpretation si that security-severity bugs are "security bugs" i.e. things that might get a CVE, since otherwise it's not really a severity so much as a general tag
<qyliss>
^^
<infinisil>
Ah yeah sounds good, removed the label again