Hi Richard, Cc: guix-devel to get more feedback: this is about adding ‘nss-certs’ by default in ‘guix shell -CN’ containers, along with a ‘--no-tls’ option to opt out:
https://issues.guix.gnu.org/70314 Richard Sent <rich...@freakingpenguin.com> skribis: > Ludovic Courtès <l...@gnu.org> writes: > >> Instead of adding the ‘nss-certs’ package, I would rather expose >> /etc/ssl/certs (when it exists), for two reasons: (1) the system-chosen >> certificates will be used, and (2) it’s less expensive than having to >> compute the derivation of ‘nss-certs’. > > There is an issue with this that's cropped up in the past. The files in > /etc/ssl/certs/* are symlinks to store items. Because containers only > see a subset of store items that are in that container's profile, it > often sees the symlinks to store items but not the target file. Oh, indeed. [...] >> Users who definitely want Guix’s ‘nss-certs’ can always add it to the >> shell and it will take precedence over /etc/ssl/certs, assuming >> SSL_CERT_{FILE,DIR} is defined. > > True, although at present anyone who wants to use nss-certs must set > SSL_CERT_{FILE,DIR} manually (or coincidentally install a package that > registers the search path). Right. [...] > My thoughts are if we have to decide between > > 1. Users who want TLS with standard public endpoints > 2. Users who want TLS with custom private endpoints > > it's better to prioritize a good experience for 1 and let 2 opt-out of > the "hand holding" defaults. But perhaps it's possible to make everyone > happy. You’ve convinced me. That it’s opt-out sounds reasonable to me. ‘--no-tls’ sounds reasonable too as a name (I thought about ‘--no-x509-certificates’ but that’s actually less accurate since there are the SSL_* variables in addition to the certificates themselves). I have some comments about the patch and I’d like others to weigh in too before we commit this change. Thank you! Ludo’.
