I wonder if instead (or in addition to) a step should be added to the
default profile to symlink nss-certs to
/etc/ssl/certs/ca-certificates.crt?
Consider running $ guix shell rust:cargo nss-certs -CN -- cargo search
ox.
On c9cd16c630 this will fail with
--8<---------------cut here---------------start------------->8---
Updating crates.io index
error: download of config.json failed
Caused by:
failed to download from `https://index.crates.io/config.json`
Caused by:
[60] SSL peer certificate or SSH remote key was not OK (server certificate
verification failed. CAfile: none CRLfile: none)
--8<---------------cut here---------------end--------------->8---
This is because /etc/ssl/certs doesn't exist in the shell's container.
A user could work around this by running in the shell:
--8<---------------cut here---------------start------------->8---
export SSL_CERT_FILE=$GUIX_ENVIRONMENT/etc/ssl/certs/ca-certificates.crt
--8<---------------cut here---------------end--------------->8---
but this complicates the handle $ guix shell ... -- <command> syntax.
The only package that seems to escape this nonfunctional trap is git
because the package definition explicitly sets a GIT_SSL_CAINFO search
path specification.
IMO, if we agree to add nss-certs to %base-packages, we should also set
up a /etc/ssl/certs symlink to %default-profile-hooks. It's very odd to
see `building CA certificate bundle...` printed to the console yet not
be able to use https except for git in shell containers.
Power users will still be able to override the normal behavior by
setting the package-specific environment variables. This change would
just change the default state from "nonfunctional" to "working".
--
Take it easy,
Richard Sent
Making my computer weirder one commit at a time.
