Hi Zixuan, This test is to verify if the specific client can avoid configuring the CA file explicitly. From the test results, the Python client works well without setting the file explicitly, while the Node.js client does not.
Currently we have already figured out the reason why only the Python client works [1] and Baodi will work on fixing the issue for Node.js clients. > The following are ca files from golang codebase BTW, the code you gave only works for Linux. On some other systems [2] [3], getting the CA file is complicated. [1] https://github.com/apache/pulsar/pull/4216 [2] https://go.dev/src/crypto/x509/root_darwin.go [3] https://go.dev/src/crypto/x509/root_windows.go Thanks, Yunze On Fri, Feb 24, 2023 at 12:11 PM Zixuan Liu <node...@gmail.com> wrote: > > This is not very friendly to explicitly set the ca file. > > Can we dynamically search the system ca file? and then go to set the ca > file to the libcurl. > > The following are ca files from golang codebase(this is what you > mentioned): > ``` > // Possible certificate files; stop after finding one. > var certFiles = []string{ > "/etc/ssl/certs/ca-certificates.crt", // > Debian/Ubuntu/Gentoo etc. > "/etc/pki/tls/certs/ca-bundle.crt", // Fedora/RHEL 6 > "/etc/ssl/ca-bundle.pem", // OpenSUSE > "/etc/pki/tls/cacert.pem", // OpenELEC > "/etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem", // CentOS/RHEL 7 > "/etc/ssl/cert.pem", // Alpine Linux > } > > // Possible directories with certificate files; all will be read. > var certDirectories = []string{ > "/etc/ssl/certs", // SLES10/SLES11, > https://golang.org/issue/12139 > "/etc/pki/tls/certs", // Fedora/RHEL > "/system/etc/security/cacerts", // Android > } > ``` > > Thanks, > Zixuan > > > > Yunze Xu <y...@streamnative.io.invalid> 于2023年2月24日周五 02:06写道： > > > I've figured out why the Python client does not suffer from this > > issue. I use `strace` to print all system calls. Then I find the > > Python client reads another cert file: > > > > ``` > > openat(AT_FDCWD, > > "/usr/local/lib/python3.8/dist-packages/certifi/cacert.pem", O_RDONLY) > > = 6 > > ``` > > > > The correct cert comes from the `certifi` package. > > > > While the Node.js client first tries to read `/etc/ssl/cert.pem`, then > > tries to read `/etc/pki/tls/certs/ca-bundle.crt` that is the libcurl's > > bundle CA cert location. Both of them don't exist. > > > > ``` > > 1828 openat(AT_FDCWD, "/etc/ssl/cert.pem", O_RDONLY) = -1 ENOENT (No > > such file or directory) > > 1891 openat(AT_FDCWD, "/etc/pki/tls/certs/ca-bundle.crt", O_RDONLY) = > > -1 ENOENT (No such file or directory) > > ``` > > > > Thanks, > > Yunze > > > > On Thu, Feb 23, 2023 at 11:50 PM Yunze Xu <y...@streamnative.io> wrote: > > > > > > Hi all, > > > > > > Currently there are two ongoing releases: Python client 3.1.0 [1] and > > > Node.js client 1.8.1 [2]. Both these two releases depend on the C++ > > > client 3.1.2, which fixes an issue that when performing OAuth2 > > > authentication with an issuer URL whose protocol is HTTPS, users can > > > configure the tls cert file path to fix it. > > > > > > However, a regression was reported in the vote mail list of Node.js > > > client [2]. In short, since Node.js client 1.8.0, users have to > > > configure the tls cert file path explicitly, while the path could be > > > detected automatically before. Since the Python client is also based > > > on the C++ client and adopts a similar way to build the binaries, I've > > > thought it should suffer the same issue. While the test result shows > > > the Python client works well. > > > > > > So I created a repository [3] to: > > > - Give an example for how to test Python and Node.js clients > > > - Report my test results on various operating systems > > > > > > Please also help verify these two candidate releases. > > > > > > [1] https://lists.apache.org/thread/0mcdfw6ogof2bcl40m9p3gjzwolr8rw2 > > > [2] https://lists.apache.org/thread/n8jrg29nmozxqp588dbd8nkm7y18sphf > > > [3] https://github.com/BewareMyPower/pulsar-tls-examples > > > > > > Thanks, > > > Yunze > >
