Updated cookie secrets management #378
Conversation
Partly addressing issue #196
from the old to the new default location
even when they came from the old default location +some small code cleanup and reduced code repetition
|
It's ready for review (and merge if accepted). One thing to consider/discuss is that it has one thing that is not backwards compatible, which is that cookie secrets from config file now are preferred over cookies from the cookie secrets file. Before this was the other way around. But, this feels more logical to me as zones in the configuration file are also preferred over zones in the zone list file. I believe there will be a negligible number of people that have cookie secrets in both the config file and in the cookie secrets file and would depend on the earlier preference to pick the secrets file. |
|
Looks reasonable to me. I agree that despite the backwards-incompatible change, it is unlikely to affect anyone, because no-one would define cookies in both places. |
Thanks @wcawijngaards ! Yes, cleanup secrets on the stack after use is definitely more secure. I think you even found some occurrences that weren't covered before. Co-authored-by: Wouter Wijngaards <wcawijngaards@users.noreply.github.com>
| default: | ||
| ssl_printf(ssl, "source : unknown\n"); | ||
| break; |
There was a problem hiding this comment.
All possibilities are covered, so this is a panic situation(?)
| return 0; | ||
| } | ||
| else if(nsd->options->cookie_secret_file != NULL /* explicit name */ | ||
| ||!(f = fopen((fn = CONFIGDIR"/nsd_cookiesecrets.txt"), "r"))) |
There was a problem hiding this comment.
Falling back to nsd_cookiesecrets.txt in this function doesn't seem right. I think it's preferred to handle that in the configuration parser (or shortly after). Maybe do something like if cookie_secret_file is still NULL after parsing, set it to the previous default? That way behavior is more deterministic. Also would avoid the cookie_secret_file function, which seems to return COOKIESECRETSFILE if the cookie_secret_file is NULL. So, basically fn is only NULL if the cookie_secret_file is not NULL but empty, in which case NULL is returned. This seems a very convoluted way of avoiding checking whether the member is NULL just after parsing and setting right then(?)
| } | ||
| } | ||
| fclose(f); | ||
| if(count && nsd->cookie_secrets_source <= COOKIE_SECRETS_FROM_FILE) { |
There was a problem hiding this comment.
An enum is mapped to an integer, but it's better to be explicit. The order might change and this may go unnoticed. Basically, you want the branch to be taken if the secret does not originate from the configuration (!= COOKIE_SECRETS_FROM_CONFIG).
This PR is in response to issue #196 (and thus also of interest to @anandb-ripencc )
--with-cookiesecretsfile=pathwithconfigure{dbdir}/cookiesecrets.txtcookie-secret-fileoption in the config file, and the new default location does not exist, cookie secrets will be read from the previous default location{configdir}/nsd_cookiesecrets.txtcookie-staging-secretoption.cookie-secretandcookie-staging-secretoption) take precedence over the ones from the cookie secret fileanswer-cookie,cookie-secret,cookie-staging-secretandcookie-secret-file) will be reevaluated and effectuated afternsd-control reconfig