View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0009005 | ardour | bugs | public | 2022-10-18 16:14 | 2022-10-31 12:35 |
| Reporter | lfont | Assigned To | x42 | ||
| Priority | normal | Severity | minor | Reproducibility | always |
| Status | resolved | Resolution | fixed | ||
| Platform | PC | OS | Fedora Linux | OS Version | 36 |
| Product Version | 7.0 | ||||
| Summary | 0009005: Session > Import > Search Freesound does not work because of an SSL CA cert error | ||||
| Description | Hello, On Ardour 7.0.0 (rev 7.0) official build, it is currently not possible to use the "Search Freesound" feature (at least on Fedora Linux 36). The Ardour log window contains this error: 2022-10-18T17:48:25 [ERROR]: curl error 77 (Problem with the SSL CA cert (path? access rights?)) 2022-10-18T17:48:25 [ERROR]: no root XML node! | ||||
| Steps To Reproduce | Open the import window: "Session > Import" Go to the third tab "Search Freesound" Type something in the "Tags" field Click on the "Search" button > The Ardour log indicator at the top right will blink in red. The window will contains the following error: ... [ERROR]: curl error 77 (Problem with the SSL CA cert (path? access rights?)) ... [ERROR]: no root XML node! | ||||
| Tags | No tags attached. | ||||
|
|
Where does Fedora keep its SSL Certs these days? is there still /etc/pki/tls/certs/ca-bundle.crt on your system, or is it newer than https://bugzilla.redhat.com/show_bug.cgi?id=1053882 ? |
|
|
A potential workaround is now in Ardour 7.0-45-g073d6f5e80 |
|
|
/etc/pki/tls/certs/ca-bundle.crt is still there and looking at the README provided by the ca-certificates package (https://src.fedoraproject.org/rpms/ca-certificates/blob/f36/f/README.etcssl) it seems that (/etc/ssl) should be compatible with Debian like distro. So I'm not sure that this https://github.com/Ardour/ardour/blob/master/gtk2_ardour/ardour_http.cc#L106 is still required. 7.0-45-g073d6f5e80 is not yet available to download, I will test it but I'm not sure about the fix as ca_info should not be empty. |
|
|
I've try to run the latest nightly build (rev 7.0-46-g22829e96b1) and I still get the same error message: strace output: stat("/etc/pki/tls/certs/ca-bundle.crt", {st_mode=S_IFREG|0444, st_size=214712, ...}) = 0 openat(AT_FDCWD, "/etc/pki/tls/certs/ca-bundle.crt", O_RDONLY) = 65 stat("/nonexistent_path", 0x7ffd799d8b50) = -1 ENOENT (No such file or directory) I've build Ardour (rev 7.0) on my system and I was not able to reproduce the issue: strace output: openat(AT_FDCWD, "/etc/crypto-policies/back-ends/openssl.config", O_RDONLY) = 62 openat(AT_FDCWD, "/etc/pki/tls/certs/ca-bundle.crt", O_RDONLY) = 62 In the second case there is not attempt to open (/nonexistent_path). I don't know if this is relevant or not, I can provide more output if needed. |
|
|
> So I'm not sure that this https://github.com/Ardour/ardour/blob/master/gtk2_ardour/ardour_http.cc#L106 is still required. Apparently it is a trap. Red Hat tries to provide a debian compatible but fails at that (see the linked bug report). I just realized that the check is incorrect. It should check for Glib::FILE_TEST_EXISTS|Glib::FILE_TEST_IS_REGULAR >I've build Ardour (rev 7.0) on my system and I was not able to reproduce the issue: The issue is only relevant for binaries from Ardour that bundle libcurl. In this case curl has to be informed where to search for SSL certs. If you compile Ardour locally and use libcurl from your GNU/Linux distro, your distro has already configured libcurl correctly. |
|
|
> Apparently it is a trap. Red Hat tries to provide a debian compatible but fails at that (see the linked bug report). Hmm, I don´t know if this has been fixed or not. Some part of the discussion seems to say yes. > If you compile Ardour locally and use libcurl from your GNU/Linux distro, your distro has already configured libcurl correctly. Sorry but I'm not familiar will all of this and I don't know how to reproduce exactly the same bundle configuration. > I just realized that the check is incorrect. It should check for Glib::FILE_TEST_EXISTS|Glib::FILE_TEST_IS_REGULAR Yes, but the result will be the same. ca_path will end up with the (/nonexistent_path) value which seems to be a problem. As Glib::file_test ("/etc/pki/tls/certs/ca-bundle.crt", Glib::FILE_TEST_EXISTS|Glib::FILE_TEST_IS_DIR) check is wrong and that (/etc/ssl/certs) exists we should not currently have (/nonexistent_path) in strace. On fedora, (/etc/ssl/certs) is a symlink to (/etc/pki/ca-trust/extracted/pem/directory-hash). |
|
|
Hi, I don't know whether there is a connection to this but I had a similar problem using the new Download-Library-Manager of Ardour on Linux. It first didn't work and I got some SSL CA cert errors. I closed Ardour and deleted the Ardour config in ~/.config/ and after starting Ardour again it worked. Before official Ardour release, I had a Nihgtly version installed, maybe that config got corrupted or something simlar. Perhaps it helps |
|
|
Thanks for the suggestion, but this is not a configuration problem. I've run different builds and do not reproduce the issue with all of them. It seems that the issue is due to the configuration of the bundled libcurl. |
|
|
I forgot to mention in the release announcement that if you had used a build of Ardour during the 7.0 development process, you should almost certainly delete or rename your ardour preferences/configuration folder. |
|
|
(I am a Fedora developer/packager (but not the owner of the Ardour package). I say that to claim a bit of relevant credibility in this area.) I can confirm the problem with Ardour binaries as reported. The problem is however not in /etc/pki/tls/certs/ca-bundle.crt . And Fedora didn't change it in any relevant way. The problem is /nonexistent_path . The invalid path makes the Ardour curl / openssl choke. Assuming it worked before, the change most be on the Ardour side. Perhaps the version on the build host (which is bundled with the binary builds) got upgraded to something more strict than before? As a workaround and evidence of the culprit, try creating an empty directory at /nonexistent_path . That makes freesound search work for me. I don't understand the comment '''don't try "/etc/ssl/certs" in case it's curl's default'''. Even though /etc/ssl/certs doesn't contain hashed certs on Fedora and thus doesn't work as openssl CA path, it still works as well as an empty directory. Evidence: it also works with "ln -s /etc/ssl/certs /nonexistent_path". I thus suggest unconditionally using ca_path = "/etc/ssl/certs". I also suggest reverting b75be7f97 and 073d6f5e. These changes doesn't seem to go in the right direction. And the introduction of the unsafe default of silently not verifying certificates seems very unfortunate. |
|
|
I proposed https://github.com/Ardour/ardour/pull/743 which has some related discussion. |
|
|
The PR proposed above has landed. I verified that Ardour-7.0.141-dbg-x86_64-gcc5.run now works smoothly when searching freesound. Both out of the box, where Fedora now has hashes in /etc/ssl/certs to be compatible with Debian, and it also works if making /etc/ssl/certs an empty directory (as it more or less has been in the past). |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2022-10-18 16:14 | lfont | New Issue | |
| 2022-10-18 16:52 | x42 | Note Added: 0026641 | |
| 2022-10-18 17:38 | x42 | Note Added: 0026643 | |
| 2022-10-18 17:38 | x42 | Assigned To | => x42 |
| 2022-10-18 17:38 | x42 | Status | new => feedback |
| 2022-10-18 20:19 | lfont | Note Added: 0026645 | |
| 2022-10-18 20:19 | lfont | Status | feedback => assigned |
| 2022-10-19 13:13 | lfont | Note Added: 0026646 | |
| 2022-10-19 14:42 | x42 | Note Added: 0026647 | |
| 2022-10-19 15:16 | lfont | Note Added: 0026648 | |
| 2022-10-19 15:30 | krischan941 | Note Added: 0026649 | |
| 2022-10-19 20:56 | lfont | Note Added: 0026651 | |
| 2022-10-21 04:47 | paul | Note Added: 0026661 | |
| 2022-10-21 23:22 | kiilerix | Note Added: 0026671 | |
| 2022-10-22 19:13 | kiilerix | Note Added: 0026672 | |
| 2022-10-28 23:09 | kiilerix | Note Added: 0026739 | |
| 2022-10-31 12:35 | x42 | Status | assigned => resolved |
| 2022-10-31 12:35 | x42 | Resolution | open => fixed |
