[-- Attachment #1: Type: text/plain, Size: 1489 bytes --] New issue by newbluemoon on void-packages repository https://github.com/void-linux/void-packages/issues/31161 Description: When trying to fetch the distfiles for `sonic-visualiser` and `vamp-plugin-sdk` there is a certificate verification failure: ``` => sonic-visualiser-4.3_1: fetching distfile 'sonic-visualiser-4.3.tar.gz'... Certificate verification failed for /jurisdictionC=GB/businessCategory=Government Entity/serialNumber=1989-08-02/C=GB/ST=Tower Hamlets/L=Bethnal Green/O=Queen Mary University of London/CN=code.soundsoftware.ac.uk SSL_connect returned 1 https://code.soundsoftware.ac.uk/attachments/download/2786/sonic-visualiser-4.3.tar.gz: Operation not permitted => ERROR: sonic-visualiser-4.3_1: failed to fetch sonic-visualiser-4.3.tar.gz. ``` ``` => vamp-plugin-sdk-2.10.0_1: fetching distfile 'vamp-plugin-sdk-2.10.0.tar.gz'... Certificate verification failed for /jurisdictionC=GB/businessCategory=Government Entity/serialNumber=1989-08-02/C=GB/ST=Tower Hamlets/L=Bethnal Green/O=Queen Mary University of London/CN=code.soundsoftware.ac.uk SSL_connect returned 1 https://code.soundsoftware.ac.uk/attachments/download/2691/vamp-plugin-sdk-2.10.0.tar.gz: Operation not permitted => ERROR: vamp-plugin-sdk-2.10.0_1: failed to fetch vamp-plugin-sdk-2.10.0.tar.gz. ``` It seems there is a problem with `code.soundsoftware.ac.uk`. However, the files can be downloaded without error using firefox or chromium. So the issue might lie with `ca-certificates`.
[-- Attachment #1: Type: text/plain, Size: 270 bytes --] New comment by ericonr on void-packages repository https://github.com/void-linux/void-packages/issues/31161#issuecomment-858229241 Comment: I can reproduce it, and `ca-certificates` doesn't seem to have new commits that I could find. `curl` gets the same errors :/
[-- Attachment #1: Type: text/plain, Size: 318 bytes --] New comment by RossComputerGuy on void-packages repository https://github.com/void-linux/void-packages/issues/31161#issuecomment-873105348 Comment: I'm having the same problem, trying to bootstrap is annoying and I cannot leave it alone. This error happens with like 90% of packages and seriously needs to be fixed.
[-- Attachment #1: Type: text/plain, Size: 265 bytes --] New comment by RossComputerGuy on void-packages repository https://github.com/void-linux/void-packages/issues/31161#issuecomment-873319167 Comment: Turns out Debian's is outdated, we should use `nss` to provide `ca-certificates`. This is exactly what Arch Linux.
[-- Attachment #1: Type: text/plain, Size: 270 bytes --] New comment by RossComputerGuy on void-packages repository https://github.com/void-linux/void-packages/issues/31161#issuecomment-873319167 Comment: Turns out Debian's is outdated, we should use `nss` to provide `ca-certificates`. This is exactly what Arch Linux does.
[-- Attachment #1: Type: text/plain, Size: 221 bytes --] New comment by ericonr on void-packages repository https://github.com/void-linux/void-packages/issues/31161#issuecomment-873320012 Comment: Sounds reasonable to open a proposal to switch. @leahneukirchen @sgn thoughts?
[-- Attachment #1: Type: text/plain, Size: 404 bytes --] New comment by RossComputerGuy on void-packages repository https://github.com/void-linux/void-packages/issues/31161#issuecomment-873323861 Comment: If we do go ahead and replace ca-certificates with an `nss` provided one, we will have to have Arch Linux's `ca-certificates-utils` package added in. However, it might be possible to combine both the utils package and `nss`+`ca-certificates` subpackage.
[-- Attachment #1: Type: text/plain, Size: 268 bytes --] New comment by RossComputerGuy on void-packages repository https://github.com/void-linux/void-packages/issues/31161#issuecomment-873358557 Comment: I've got the `nss` + `ca-certificates` package implemented in my fork. If going ahead, I can open a PR for adding it.
[-- Attachment #1: Type: text/plain, Size: 238 bytes --] New comment by ericonr on void-packages repository https://github.com/void-linux/void-packages/issues/31161#issuecomment-881799954 Comment: The best way to start a discussion is opening a PR. I think @sgn was looking into this as well.
[-- Attachment #1: Type: text/plain, Size: 979 bytes --] New comment by sgn on void-packages repository https://github.com/void-linux/void-packages/issues/31161#issuecomment-881979791 Comment: Hm, the problem is not our `ca-certificates`, https://code.soundsoftware.ac.uk is signed by an intermediate certfificates, which in turn signed by `QuoVadis Root CA 2 G3`, our current ca-certificates has that root certs already. However, https://code.soundsoftware.ac.uk doesn't send the full certificate chain, so neither openssl nor curl can verify. You can confirm by: ```sh { curl -L http://trust.quovadisglobal.com/quovadiseuropeevsslcag1.crt | openssl x509 -inform DER -outform PEM openssl s_client -showcerts -servername code.soundsoftware.ac.uk -connect code.soundsoftware.ac.uk:443 </dev/null } >fullchain.pem openssl verify fullchain.pem ``` Solution: - Each of those servers should send the full chain; or - Changing out libfetch to inspect certificate and download the intermediate certificates.
[-- Attachment #1: Type: text/plain, Size: 709 bytes --] New comment by sgn on void-packages repository https://github.com/void-linux/void-packages/issues/31161#issuecomment-881979882 Comment: > Turns out Debian's is outdated, we should use `nss` to provide `ca-certificates`. This is exactly what Arch Linux does. The root certs for `code.soundsoftware.ac.uk` is there, Debian's ca-certificates is outdated, but it's irrelevant. > If we do go ahead and replace ca-certificates with an `nss` provided one, we will have to have Arch Linux's `ca-certificates-utils` package added in. However, it might be possible to combine both the utils package and `nss`+`ca-certificates` subpackage. We don't need to go with RedHat route. My proposal works just fine.
[-- Attachment #1: Type: text/plain, Size: 1123 bytes --] New comment by sgn on void-packages repository https://github.com/void-linux/void-packages/issues/31161#issuecomment-881979791 Comment: Hm, the problem is not our `ca-certificates`, https://code.soundsoftware.ac.uk is signed by an intermediate certfificates, which in turn signed by `QuoVadis Root CA 2 G3`, our current ca-certificates has that root certs already. However, https://code.soundsoftware.ac.uk doesn't send the full certificate chain as it should (https://crypto.stackexchange.com/questions/63907/why-does-curl-need-both-root-and-intermediate-certificates-in-order-to-securely), so neither openssl nor curl can verify. You can confirm by: ```sh { curl -L http://trust.quovadisglobal.com/quovadiseuropeevsslcag1.crt | openssl x509 -inform DER -outform PEM openssl s_client -showcerts -servername code.soundsoftware.ac.uk -connect code.soundsoftware.ac.uk:443 </dev/null } >fullchain.pem openssl verify fullchain.pem ``` Solution: - Each of those servers should send the full chain; or - Changing out libfetch to inspect certificate and download the intermediate certificates.
[-- Attachment #1: Type: text/plain, Size: 191 bytes --] New comment by sgn on void-packages repository https://github.com/void-linux/void-packages/issues/31161#issuecomment-882543882 Comment: I think nothing we can do in void-packages. Closing?
[-- Attachment #1: Type: text/plain, Size: 362 bytes --] New comment by ericonr on void-packages repository https://github.com/void-linux/void-packages/issues/31161#issuecomment-882667630 Comment: If even curl doesn't support this use case, I don't see why libfetch should. They should fix the server. I think we should find a better mirror for the files or mirror them ourselves before closing the issue, though.
[-- Attachment #1: Type: text/plain, Size: 604 bytes --] New comment by sgn on void-packages repository https://github.com/void-linux/void-packages/issues/31161#issuecomment-884044180 Comment: > If even curl doesn't support this use case, I don't see why libfetch should. They should fix the server. curl puts it in TODO list. Given the length of TODO list, I think it will take some time. https://github.com/curl/curl/blob/bfbde883af33397943df68a3ae01847a634d33bf/docs/TODO#L117 https://github.com/curl/curl/issues/2793 > I think we should find a better mirror for the files or mirror them ourselves before closing the issue, though. Agree!
[-- Attachment #1: Type: text/plain, Size: 735 bytes --] New comment by sgn on void-packages repository https://github.com/void-linux/void-packages/issues/31161#issuecomment-884044180 Comment: > If even curl doesn't support this use case, I don't see why libfetch should. They should fix the server. curl puts it in TODO list. Given the length of TODO list, I think it will take some time. https://github.com/curl/curl/blob/bfbde883af33397943df68a3ae01847a634d33bf/docs/TODO#L117 > Since AIA is about downloading certs on demand to complete a TLS handshake, > it is probably a bit tricky to get done right. https://github.com/curl/curl/issues/2793 > I think we should find a better mirror for the files or mirror them ourselves before closing the issue, though. Agree!
[-- Attachment #1: Type: text/plain, Size: 357 bytes --] New comment by newbluemoon on void-packages repository https://github.com/void-linux/void-packages/issues/31161#issuecomment-884192327 Comment: Arch fetches the sources for sonic-visualiser from bintray.com (cf. https://github.com/archlinux/svntogit-community/blob/packages/sonic-visualiser/trunk/PKGBUILD), but I don’t think it’s an official mirror.
[-- Attachment #1: Type: text/plain, Size: 166 bytes --] New comment by leahneukirchen on void-packages repository https://github.com/void-linux/void-packages/issues/31161#issuecomment-884194137 Comment: bintray is dead.
[-- Attachment #1: Type: text/plain, Size: 214 bytes --] New comment by newbluemoon on void-packages repository https://github.com/void-linux/void-packages/issues/31161#issuecomment-884199334 Comment: > bintray is dead. Alright, that question solved itself then. ;)
[-- Attachment #1: Type: text/plain, Size: 279 bytes --] New comment by newbluemoon on void-packages repository https://github.com/void-linux/void-packages/issues/31161#issuecomment-884204384 Comment: Debian is still at sonic-visualiser-4.2, but upstream is at 4.3, so maybe self-mirroring the sources in question is the best option?
[-- Attachment #1: Type: text/plain, Size: 293 bytes --] New comment by github-actions[bot] on void-packages repository https://github.com/void-linux/void-packages/issues/31161#issuecomment-1132374946 Comment: Issues become stale 90 days after last activity and are closed 14 days after that. If this issue is still relevant bump it or assign it.
[-- Attachment #1: Type: text/plain, Size: 1492 bytes --] Closed issue by newbluemoon on void-packages repository https://github.com/void-linux/void-packages/issues/31161 Description: When trying to fetch the distfiles for `sonic-visualiser` and `vamp-plugin-sdk` there is a certificate verification failure: ``` => sonic-visualiser-4.3_1: fetching distfile 'sonic-visualiser-4.3.tar.gz'... Certificate verification failed for /jurisdictionC=GB/businessCategory=Government Entity/serialNumber=1989-08-02/C=GB/ST=Tower Hamlets/L=Bethnal Green/O=Queen Mary University of London/CN=code.soundsoftware.ac.uk SSL_connect returned 1 https://code.soundsoftware.ac.uk/attachments/download/2786/sonic-visualiser-4.3.tar.gz: Operation not permitted => ERROR: sonic-visualiser-4.3_1: failed to fetch sonic-visualiser-4.3.tar.gz. ``` ``` => vamp-plugin-sdk-2.10.0_1: fetching distfile 'vamp-plugin-sdk-2.10.0.tar.gz'... Certificate verification failed for /jurisdictionC=GB/businessCategory=Government Entity/serialNumber=1989-08-02/C=GB/ST=Tower Hamlets/L=Bethnal Green/O=Queen Mary University of London/CN=code.soundsoftware.ac.uk SSL_connect returned 1 https://code.soundsoftware.ac.uk/attachments/download/2691/vamp-plugin-sdk-2.10.0.tar.gz: Operation not permitted => ERROR: vamp-plugin-sdk-2.10.0_1: failed to fetch vamp-plugin-sdk-2.10.0.tar.gz. ``` It seems there is a problem with `code.soundsoftware.ac.uk`. However, the files can be downloaded without error using firefox or chromium. So the issue might lie with `ca-certificates`.