Hi, Ricardo Wurmus <[email protected]> writes:
> ng0 <[email protected]> writes: > >> Ricardo Wurmus <[email protected]> writes: >> >>> myglc2 <[email protected]> writes: >>> >>>> With GuixSD user config ... >> …… >>>> ) >>> >>> You forgot to actually add “nss-certs” to the manifest. After adding >>> “nss-certs” you need to set the environment variable CURL_CA_BUNDLE: >>> >>> export >>> CURL_CA_BUNDLE=/home/rekado/.myglc2-profile/etc/ssl/certs/ca-certificates.crt >>> >>> (I only recently patched r-curl to respect this environment variable. >>> We should patch libcurl so that all packages using libcurl understand >>> it.) >>> >> >> I wonder if we need this for gnurl or if the code base of gnurl is still >> curl-like enough that it respects the variable.. last time I tried gnurl >> as a user on its own (which is *not* the intended use) was on Gentoo. >> Gnurl is afaik not (yet) a gnu project and requires no sync with the gnu >> descriptions.. I should add this to the description. > > Looking at the sources and searching for “getenv” I see this: Thanks for your reply. I'll see that I address the issue in the next version release of gnurl. Prior to using GuixSD I wasn't aware of this, and I do my test builds of gnurl on guixsd and gentoo to assure that there's no mistake from either systems side. > … > gnurl-7_50_3/src/tool_operate.c: env = curlx_getenv("CURL_CA_BUNDLE"); > gnurl-7_50_3/src/tool_operate.c: env = curlx_getenv("SSL_CERT_DIR"); > gnurl-7_50_3/src/tool_operate.c: env = curlx_getenv("SSL_CERT_FILE"); > gnurl-7_50_3/gnurl--/src/tool_operate.c: env = > curlx_getenv("CURL_CA_BUNDLE"); > gnurl-7_50_3/gnurl--/src/tool_operate.c: env = > curlx_getenv("SSL_CERT_DIR"); > gnurl-7_50_3/gnurl--/src/tool_operate.c: env = > curlx_getenv("SSL_CERT_FILE"); > gnurl-7_50_3/gnurl--/lib/Makefile.netware: @echo $(DL)#define > CURL_CA_BUNDLE getenv("CURL_CA_BUNDLE")$(DL) >> $@ > gnurl-7_50_3/gnurl--/lib/curl_setup.h:#define CURL_CA_BUNDLE > getenv("CURL_CA_BUNDLE") > gnurl-7_50_3/gnurl--/lib/vtls/nss.c: cert_dir = getenv("SSL_DIR"); > gnurl-7_50_3/gnurl--/lib/config-dos.h:#define CURL_CA_BUNDLE > getenv("CURL_CA_BUNDLE") > gnurl-7_50_3/lib/Makefile.netware: @echo $(DL)#define CURL_CA_BUNDLE > getenv("CURL_CA_BUNDLE")$(DL) >> $@ > … > > It looks like these common environment variables are indeed used for the > tool. For the library it seems that the environment variable is only > respected when “config-dos.h” is used. In other cases it’s a fixed file > path: > > gnurl-7_50_3/src/Makefile:CURL_CA_BUNDLE = > "/etc/ssl/certs/ca-certificates.crt" > > So gnurl should also be patched to replace the definition of > CURL_CA_BUNDLE with “getenv("CURL_CA_BUNDLE")”. > >> But can you share some insights why curl requires this? For gnurl I rely >> on its test suite, but I think curl does not complain about the missing >> CURL_CA_BUNDLE in its test suite either, or does it? > > libcurl expects the user to configure the location of the bundle. If > this does not happen it defaults to some hardcoded file path. The > command line tool uses libcurl and overrides the value when the > environment variable CURL_CA_BUNDLE is set. > > On Guix we cannot guarantee the existence of the hardcoded default path. > The bundle is not part of the curl package and we cannot presume to know > where the bundle file will be stored. For per-profile certificates (a > user might want to distrust certain certificates, while another might > want to use the defaults) we should not hardcode this but defer the > decision to the CURL_CA_BUNDLE environment variable. > >> And if gnurl should require this, how could I fix gnurl (not the package >> description in guix) to drop this strange behavior if it is possible at >> all? > > It would be the same patch: we need to define CURL_CA_BUNDLE to be > “getenv("CURL_CA_BUNDLE)” instead of a fixed path. > > ~~ Ricardo > > --
