| 5 Mar 2022 |
Winter (she/her) | In reply to @m1cr0man:m1cr0man.com Yeah that's probably best, and so that it's on record on Github too Would it be appropriate to label the issue as a bug? | 19:34:00 |
Winter (she/her) | (don't wanna open an issue with no label idk) | 19:34:07 |
Winter (she/her) | i think so | 19:34:22 |
m1cr0man | hah uh idk what label to use honestly 😅 I think it's more just discussion atm, nothing is wrong per se | 19:34:33 |
m1cr0man | * hah uh idk what label to use honestly 😅 I think it's more just discussion/suggestion atm, nothing is wrong per se | 19:34:40 |
Winter (she/her) | true | 19:34:43 |
Winter (she/her) | yeah ill do no label | 19:34:53 |
Winter (she/her) | m1cr0man: am i just blind, or is the group option for not defined in certOpts? | 19:51:09 |
Winter (she/her) | * m1cr0man: am i just blind, or is the group option not defined in certOpts? | 19:51:14 |
m1cr0man | it's defined in the inheritableModule thing | 19:51:23 |
Winter (she/her) | oh | 19:51:53 |
Winter (she/her) | group = mkOption {
type = types.str;
inherit (defaultAndText "group" "acme") default defaultText;
description = "Group running the ACME client.";
};
i feel like this description is inaccurate?
| 19:52:02 |
Winter (she/her) | oh nevermind | 19:52:24 |
Winter (she/her) | guess its not | 19:52:27 |
Winter (she/her) | # Group might change between runs, re-apply it
chown '${user}:${data.group}' certificates/*
hm
| 19:52:57 |
m1cr0man | yeah that's 100% necessary | 19:53:11 |
m1cr0man | ran into it myself and covered by the test suite | 19:53:19 |
Winter (she/her) | so is that if the certificate doest have to be renewed, but the group changed? | 19:53:33 |
Winter (she/her) | * so is that for if the certificate doesn't have to be renewed, but the group changed? | 19:53:41 |
m1cr0man | that description might be a bit misleading I agree. It shuold maybe indicate that group will own the certs | 19:53:41 |
m1cr0man | yeah exacrly | 19:53:46 |
Winter (she/her) | got it | 19:53:48 |
m1cr0man | * yeah exactly | 19:53:49 |
Winter (she/her) |
Secondly there was in the past some concern raised around granting acme group to other services because it would grant that service access to more certs than you may want. You might get some backlash in that regard. In reality, this is hard to operate around and for wildcard certs you're likely to only have 1 cert shared across multiple services anyway.
so the thing about this point is that, like, if you set a specific group for a cert (that isn't acme), then its not like granting the acme group will give you access to those...
| 19:54:47 |
Winter (she/her) | it'll just give the acme owned ones | 19:54:55 |
Winter (she/her) | like, i get the issue in theory, and i agree with it
but not practically? | 19:55:08 |
Winter (she/her) | like i guess it's just about reducing attack surface no matter the setup | 19:55:18 |
m1cr0man | well if you aren't using wildcards its more apparent - certs for each service, with the group assigned appropriately | 19:55:39 |
Winter (she/her) | but giving the acme group won't give access to those? | 19:55:58 |
Winter (she/her) | that's the point i'm trying to make, unless i'm wrong | 19:56:07 |