Hi Ethan, I'm also using Guix on a foreign distribution (Debian) Ethan Blanton via Bug reports for GNU Guix writes: > I had read the X.509 Certificates section of the manual, but since my > certificates ARE in the default location of /etc/ssl/certs, and > vdirsyncer had previously worked, for some reason I did not dig into > it deeply enough, or perhaps I attempted to set it up wrongly at some > point in the past. I'm pretty sure my default profile vdirsyncer was working in the past but stopped working while ago for this very same issue [1]; vdirsyncer it's not working in my default profile but it's working in my "emacs" profile Reading (again) the "X.509 Certificates" section [2] I realized that I had not set up SSL_CERT_DIR and SSL_CERT_FILE env variables in my .profile After adding this to my .profile: --8<---------------cut here---------------start------------->8--- export SSL_CERT_DIR="$HOME/.guix-profile/etc/ssl/certs" export SSL_CERT_FILE="$HOME/.guix-profile/etc/ssl/certs/ca-certificates.crt" --8<---------------cut here---------------end--------------->8--- now "vdirsyncer sync" is working (in my default profile, including cron jobs) As I said before, the SSL_CERT_* variables setting was/is not necessary in my emacs profile and it depends on this: within a shell in my emacs profile I have: --8<---------------cut here---------------start------------->8--- $: cat $GUIX_PROFILE/etc/profile | grep -i ssl export CURL_CA_BUNDLE="${GUIX_PROFILE:-/gnu/store/hwc2pm42r2xg3mv0f7jlkf7dlvi6rpxh-profile}/etc/ssl/certs/ca-certificates.crt" export SSL_CERT_FILE="${GUIX_PROFILE:-/gnu/store/hwc2pm42r2xg3mv0f7jlkf7dlvi6rpxh-profile}/etc/ssl/certs/ca-certificates.crt" export SSL_CERT_DIR="${GUIX_PROFILE:-/gnu/store/hwc2pm42r2xg3mv0f7jlkf7dlvi6rpxh-profile}/etc/ssl/certs" export GIT_SSL_CAINFO="${GUIX_PROFILE:-/gnu/store/hwc2pm42r2xg3mv0f7jlkf7dlvi6rpxh-profile}/etc/ssl/certs/ca-certificates.crt" --8<---------------cut here---------------end--------------->8--- within a shell in my default profile: --8<---------------cut here---------------start------------->8--- $: cat $GUIX_PROFILE/etc/profile | grep -i ssl export GIT_SSL_CAINFO="${GUIX_PROFILE:-/gnu/store/ylycvfsnm1gkzhph39g62bwbc9lbh3g7-profile}/etc/ssl/certs/ca-certificates.crt" --8<---------------cut here---------------end--------------->8--- For sure it depends on the fact that an installed package in my emacs profile (curl, not installed in my default profile) is adding "SSL_CERT_FILE" and "SSL_CERT_DIR" in $GUIX_PROFILE/etc/profile Since I usually source the latter when I switch to my "emacs" profile before starting emacs in a shell: --8<---------------cut here---------------start------------->8--- GUIX_PROFILE="$GUIX_EXTRA_PROFILES"/emacs/emacs; . "$GUIX_PROFILE"/etc/profile --8<---------------cut here---------------end--------------->8--- I get the two env variables defined in my "emacs" profile, while in my default profile I don't > Setting SSL_CERT_DIR=/etc/ssl/certs in my environment fixes the > vdirsyncer package, and it syncs correctly. I'd use the Guix certs installed via nss-certs, but both dirs works obviously Please note that you should set SSL_CERT_FILE for other software > I have also discovered that python aiohttp will correctly verify > certificates WITHOUT this environment variable with: > > guix shell -P -C -N python python-aiohttp nss-certs openssl > > Leaving out EITHER nss-certs OR openssl causes aiohttp to exhibit the > same behavior as vdirsyncer. > > However, including both of these packages in the same (foreign distro) > profile that includes vdirsyncer does NOT cause vdirsyncer to > correctly verify certificates. Strange behaviour, please can you tell us what is the output of this command: --8<---------------cut here---------------start------------->8--- guix shell --pure --container coreutils grep nss-certs openssl -- env | grep -i ssl --8<---------------cut here---------------end--------------->8--- I get this (meaning that both SSL env variables are defined): --8<---------------cut here---------------start------------->8--- SSL_CERT_DIR=/gnu/store/1ghginmnzplmp3nbv2jsavjgdjhgq4i3-profile/etc/ssl/certs SSL_CERT_FILE=/gnu/store/1ghginmnzplmp3nbv2jsavjgdjhgq4i3-profile/etc/ssl/certs/ca-certificates.crt --8<---------------cut here---------------end--------------->8--- while with --8<---------------cut here---------------start------------->8--- guix shell --pure --container coreutils grep nss-certs -- env | grep -i ssl --8<---------------cut here---------------end--------------->8--- I get no output (meaning that env is missing SSL_CERT_* variables) So in my tests openssl (and curl) are defining "SSL_CERT_FILE" and "SSL_CERT_DIR" in $GUIX_PROFILE/etc/profile I guess that also nss-certs package could add both "SSL_CERT_FILE" and "SSL_CERT_DIR" in $GUIX_PROFILE/etc/profile but I don't know the ratio for this choiche > I am not sure what this means for this bug; certainly the change from > "working without extra configuration" to "broken without extra > configuration" is a regression in user experience, but it may be that > it is working as intended. The bug I see here is that X.509 certificates are "working without extra configuration" **depending** on installed packages. If possible I'd patch nss-certs in order to add "SSL_CERT_FILE" and "SSL_CERT_DIR" to $GUIX_PROFILE/etc/profile, this would also avoid the extra step of "manually" defining X.509 related variables on foreign distros I'd also investigate this "meta-issue" for other packages, e.g. for R that needs "CURL_CA_BUNDLE", added when installing curl but not r-minimal > It seems to me that the principle of least astonishment for foreign > distro users would suggest that python aiohttp defaults to loading > /etc/ssl/certs from the foreign distro, if present. IMHO it's better to use the nss-certs installed via Guix than the foreign distro ones HTH! Gio' [1] maybe I was using a Guix package able to add "SSL_CERT_FILE" and "SSL_CERT_DIR" to $GUIX_PROFILE/etc/profile and then I removed it [2] https://guix.gnu.org/en/manual/en/html_node/X_002e509-Certificates.html -- Giovanni Biscuolo Xelera IT Infrastructures