Mark H Weaver <m...@netris.org> skribis: > l...@gnu.org (Ludovic Courtès) writes: > >> Mark H Weaver <m...@netris.org> skribis: >> >>> In order to support multiple packages containing CA certs, it would be >>> good to handle creation of the single-file cert bundle in the profile >>> generation code, analogous to our handling of info "dir" files. This >>> would allow us to create additional cert packages (e.g. one for >>> CAcert.org). >>> >>> I think it belongs in the profile generation code for the benefit of >>> users running Guix packages on top of another distro, where they might >>> not have root access. They can simply set GIT_SSL_CAINFO and >>> SSL_CERT_FILE to ~/.guix-profile/etc/ssl/ca-certificates.crt >>> >>> What do you think? >> >> It’s a good but as of yet unimplemented idea. >> >> Although I now realize we could perhaps simple move the >> ‘certificate-bundle’ procedure to (guix profile), add the certificate >> package to the system profile, and make /etc/ssl a symlink to >> /run/current-system/profile/etc/ssl. > > I've attached patches that implement this. They assume that 993300f and > e979e6d are first reverted. Comments and suggestions welcome.
Both look good to me. > It would also be good to add search-path-specifications for > SSL_CERT_FILE to 'openssl' and GIT_SSL_CAINFO to 'git' in core-updates, > but I'm not sure how best to do that. Would you be willing to do it, > Ludovic? I just checked the source and OpenSSL itself does not use SSL_CERT_FILE nor SSL_CERT_DIR at all. Lynx does use SSL_CERT_FILE, but that’s really in Lynx, not in libssl. So I don’t think there should be a search path specification for OpenSSL. This is unfortunate, but it looks like we can’t do much. We could add that variable to Lynx itself, but it’s not actually a search path but just a file name. Thoughts? > +# These variables are honored by OpenSSL (libssl) and Git. Replace “OpenSSL (libssl)” by “some applications such as Lynx”. Thanks, Ludo’.
