Hi,
I don’t know if this is strictly a flox problem but I created an environment containing curl-8.4.0 and openssl-3.0.13.
When I try to get something with curl --proto '=https' --tlsv1.2 -sSfL, I am getting an error (which is cryptic to me):
curl: (35) OpenSSL/3.0.13: error:16000069:STORE routines::unregistered scheme
Is something missing in my environment?
Thanks.
i’m not sure if it helps but I installed the versions of both of those packages on my mac and a debian machine and i’m able to curl --proto '=https' --tlsv1.2 -sSfL https://google.com without seeing that error
I fixed this issue by downloading the cacert.pm file from here and moving it to /etc/ssl/certs/ca-bundle.crt.
curl was working for me before and I can see a flox .crt file in /etc/ssl/certs/:
flox-ca-bundle.crt -> /nix/store/d9qdiyphispfjnyj9lb5kwrz144as3dm-nss-cacert-3.95/etc/ssl/certs/ca-bundle.crt*
So I wonder if something in the flox install could have wiped out the previous certificates?
Anyway, hopefully this solution can help other people with the same issue.
Maybe a follow-up question, from a flox point of view is: should such a file be part of my flox environment and be found by the curl executable I installed in that environment?.
I don’t believe the flox installer will do anything disruptive with existing certs but i’ll give a few things a try to verify. the installer does install a cert there for use with Flox’s internals
we’re finding there are two contexts to environments right now. environments that depend on being in a project root and its relative files and environments that need to work from anywhere. at the moment we don’t support providing additional files with environment definition so your shell hooks and variables need to do the lifting to get the right context into place and, depending on which context you need, that can make it a bit trickier to get a script that will work anywhere. one good place we’ve found to stick things those ‘run anywhere’ environments may need is the ~/.cache/flox directory
This is possibly related to non-interactive `flox activate` (from dotfile) does not set same env variables as activation from controlling TTY · Issue #817 · flox/flox · GitHub. Do you get the same error if you flox activate and then use curl in a sub-shell? Or is that already what you’re doing?
Yes indeed. If I go flox activate instead of . <(flox activate) then curl works ok.
Should be fixed in the next release, let us know if it isn’t!
I’ll test it as soon as it’s out, thanks!