<srk>
(but thinks might have changed, need to take a look / try it)
Guest14472 has quit [Client Quit]
<flokli>
srk: core(5): The process runs in the initial namespaces (PID, mount, user, and so on) and not in the namespaces of the crashing process. One can utilize specifiers such as %P to find the right /proc/[pid] directory and probe/enter the crashing process's namespaces if needed.
Jackneill has quit [Remote host closed the connection]
<flokli>
hmmh
<srk>
statistics are fun as well!
<flokli>
srk: if you don't see a lot of crashes in a while and want to debug some, yubioath-desktop coredumps every time I close it :-)
<srk>
heh, when I think about it I have few coredump of eternal-terminal which has much worse impact :(
<flokli>
coredumpctl debug goes brrr
<gchristensen>
lol
Jackneill has joined #nixos-dev
alp has joined #nixos-dev
<b42>
flokli: do you know if nixos/tests/common/acme/{client,server} is supposed to be generally usable by tests that obtain certificates from LE, or is it intended for nixos/tests/acme.nix only?
<flokli>
I think currently it isn't, but there's plans on making it so
<flokli>
so ideally tests with modules usually making use of acme certificates can just include the "acme server infrastructure", and a per-machine configuration snippet
<flokli>
there should be an issue/discussion on GH somewhere about this
<b42>
right ... it seems that the certificates that pebble hands out are signed by other CA than the one in snakeoil-certs.nix so TLS clients don't accept them
<andi->
I still don't know why we roll our own spam based banning and not just use Sigyn.
<adisbladis>
gchristensen: So we could put the rules under secrets and keep the generic stuff public :)
<gchristensen>
andi-: we do use sigyn
<MichaelRaskin>
gchristensen: I would probably add some truly stupid auto-ban (like four copies of the same expletive in a row?) as a format demo, then yeah, the real rules could be secret
<gchristensen>
this was before we were allowed to use sigyn. i didn't know you had a long-running confusion about why we didn't use sigyn :)
<gchristensen>
that is why I proposed deleting the ban rules
<MichaelRaskin>
Ah
<andi->
gchristensen: tbh I think I brought it up a few times already and never got a reply..
ixxie has quit [Ping timeout: 240 seconds]
<gchristensen>
ah
<gchristensen>
the down side to sigyn is, as you can see, we don't have sigyn now -- they don't keep it in everychannel that wants it, so it has to be requested each time
<flokli>
can't you just invite sigyn?
<gchristensen>
flokli: not when it is very busy, no
<gchristensen>
at least, it has never worked during busy times
<gchristensen>
during big spam waves, have to go find an active netop and request it for a list of channels, and they'll only do it in channels of a certain size. so #nixos would get it, maybe this one, but probably not any other of our channels
<andi->
There is always the +r mode that we can set on our channels during these times. I guess we just have to distribute the ability to do so (in some way). We can go full engineering and hack our own solution or just use chanserv/groupserv permissions :)
<gchristensen>
and when {^_^} initially got ban support, it was because sigyn couldn't join many channels at all
<gchristensen>
I hope that explains it
<flokli>
can't we just invite sigyn to the bigger channels now, and use chanserv/groupserv to allow setting +r for the smaller channels if things are busy
<gchristensen>
sure
<gchristensen>
like I said, I want to delete ban support lol
<flokli>
ok
<gchristensen>
what is groupserv?
<andi->
you can add people to groups and then hand out permissiosn to groups of people
<gchristensen>
freenode has this?
<andi->
apparently not, shocking
<gchristensen>
at any rate, that concept sounds good to me
<hexa->
ouch, no groupserv? :<
<gchristensen>
I would like to do that in principle, find out how to do it best on freenode, and let's do it? :)
<hexa->
if freenode does not have group based access you'll basically have two options
<hexa->
a) maintain access lists by hand
<hexa->
b) have a bot wrap actions
<qyliss>
FireFly: do you have any advice here?
<hexa->
b) would be something like limnoria, which has chantracker for abuse prevention
<hexa->
which is similar to sigyn, but on a channel basis
<b42>
too bad, having to copy it around at runtime is a bit inconvenient
<emily>
but I don't really see the advantage -- I think it makes sense to test the functionality of getting the root CA out, and curl's --cacert works fine. I guess it'd be a pain if you wanted to test clients that don't let you override the CAs, maybe I just have limited imagination for why someone would want to do that in a test with acme
<emily>
PEBBLE_ALTERNATE_ROOTS seems pretty much undocumented too
<b42>
especially when there's no (simple) way to add the CA to the system CA bundle at runtime
<b42>
is there something like --cacert but for firefox?
<flokli>
emily: my idea is to include some common things in other tests, that spin up helper machines simulating LE, and configure clients to just trust the CA without having to manually override more stuff at runtime
<emily>
fwiw I'd rather move in the direction of having fewer static snakeoil CAs in nixpkgs, we could get rid of the existing one for pebble if they included acme.test or something more reasonable than just localhost/pebble in the CNs, considered opening an issue for that
phreedom has joined #nixos-dev
<emily>
I think in general there's a tension between pebble designed to test edge-cases of ACME setups and just wanting TLS certificates in tests
<emily>
though probably not so much that it'd ever be worth going back to boulder for non-acme-specific tests
<emily>
like pebble is designed to be as inconvenient as possible to just get some certs with, deliberately, because it's insecure
alp has quit [Quit: Leaving]
alp has joined #nixos-dev
pie_[bnc] is now known as pie_
phreedom has quit [Remote host closed the connection]
phreedom has joined #nixos-dev
<arianvp>
I created a new #nixos-acme channel emily feel free to join
alp has quit [Ping timeout: 260 seconds]
rsa has quit [Ping timeout: 244 seconds]
NinjaTrappeur has quit [Quit: WeeChat 2.8]
NinjaTrappeur has joined #nixos-dev
alp has joined #nixos-dev
aranea has joined #nixos-dev
alp has quit [Quit: Leaving]
cdepillabout has joined #nixos-dev
cole-h has joined #nixos-dev
nschoe has quit [Quit: No Ping reply in 180 seconds.]
nschoe has joined #nixos-dev
<gchristensen>
it seems weird / wrong that searching nginx in the options list shows you all the dokuwiki's duplicated nginx options first
<gchristensen>
and matomo
<MichaelRaskin>
Hmmm. So the sorting needs to prioritise option name match, and inside that — attribute depth?
<gchristensen>
not sure
<gchristensen>
I guess I'm not sure even why matomo and dokuwiki have duplicated them so much anyway?
<infinisil>
Hmm yeah that's not very good
<infinisil>
Like this there's multiple ways of controlling mamoto nginx options
cdepillabout has quit [Quit: Leaving]
ixxie has joined #nixos-dev
Scriptkiddi has quit [Quit: killed]
das_j has quit [Quit: killed]
ajs124 has joined #nixos-dev
Scriptkiddi has joined #nixos-dev
das_j has joined #nixos-dev
asbachb has joined #nixos-dev
FRidh has quit [Quit: Konversation terminated!]
asbachb has quit [Ping timeout: 245 seconds]
teto has quit [Ping timeout: 272 seconds]
<sphalerite>
maybe there should be a "types.see" that copies the type from another option but refers to that option rather than duplicating its hierarchy
<sphalerite>
so it would be something like `options.services.matomo.nginx = types.see "options.services.nginx.virtualHosts"