--- Begin Message ---
|
Subject: |
X.509 certificate of 'crates.io' could not be verified during a recursive import from crates.io |
|
Date: |
Thu, 2 Jan 2020 01:45:35 +0300 |
Hi! I'm trying to recursively import a package from crates.io like this:
guix import crate notify@4.0.14 --recursive
It follows redirections for a while untill at some point throws this:
Backtrace:
12 (primitive-load "/home/vj/.config/guix/current/bin/guix")
In guix/ui.scm:
1806:12 11 (run-guix-command _ . _)
In guix/scripts/import.scm:
116:11 10 (guix-import . _)
In guix/scripts/import/crate.scm:
103:16 9 (guix-import-crate . _)
In guix/import/utils.scm:
425:7 8 (recursive-import _ _ #:repo->guix-package _ #:guix-name …)
397:31 7 (topological-sort _ #<procedure 7f9a59729630 at guix/i…> …)
In srfi/srfi-1.scm:
592:17 6 (map1 ("tempfile"))
In guix/import/utils.scm:
421:36 5 (lookup-node "tempfile")
In guix/import/crate.scm:
222:10 4 (crate->guix-package "tempfile" _)
150:15 3 (make-crate-sexp #:name _ #:version _ #:cargo-inputs _ # …)
In guix/http-client.scm:
88:25 2 (http-fetch _ #:port _ #:text? _ #:buffered? _ # _ # _ # …)
In guix/build/download.scm:
419:4 1 (open-connection-for-uri _ #:timeout _ # _)
306:6 0 (tls-wrap #<closed: file 7f9a564b3a10> _ # _)
guix/build/download.scm:306:6: In procedure tls-wrap:
X.509 certificate of 'crates.io' could not be verified:
signer-not-found
invalid
I suspect that it happens after the importer hits
"wasm-bindgen-webidl" and starts going circles. Maybe there's some
circullar dependencies going on, but I'm not sure. I'm attaching a
full log for convenience.
For additional info: I'm running Guix on Arch Linux. I've also
installed nss-certs package, exported all neeeded variables
(SSL_CERT_DIR, SSL_CERT_FILE and GIT_SSL_CAINFO) before running guix
import and also made sure nscd.service is running.
Regards,
Valentin Ignatev
crates_recursive_importer.log
Description: Text Data
--- End Message ---
--- Begin Message ---
|
Subject: |
Re: bug#20145: (guix build download) leaks file descriptor on TLS connections |
|
Date: |
Fri, 03 Jan 2020 16:12:11 +0100 |
|
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux) |
Hello again!
Ludovic Courtès <address@hidden> skribis:
> Back in 2015, I closed <https://issues.guix.gnu.org/issue/20145> saying:
>
>> address@hidden (Ludovic Courtès) skribis:
>>
>>> When opening an HTTPS connection, the file descriptor beneath the port
>>> returned by ‘tls-wrap’ is leaked.
>>>
>>> This is not a problem in most cases (downloads) because the process is
>>> left as soon as the download is over.
>>>
>>> This is more problematic for ‘guix lint’, which may open a large number
>>> of HTTPS connections for the ‘source’ and ‘home-page’ checkers when
>>> working on all the packages.
>>
>> This is essentially solved by commits
>> 14d6ca3e4dd23ee92adb5e2fcf58546e67534631 and
>> 097a951e96718a037dbfa6d579e2d26f7dab3e82.
>>
>> One still needs to be careful, though, for instance because closing a
>> chunked encoding port (which is a custom binary input port wrapped
>> around the real socket port) still fails to close the raw socket port
>> that’s behind the TLS session record port.
>
> Unfortunately, the bug just reported by Valentin and by Ricardo are
> instances of this problem (at least I checked with crates.io and it
> uses chunked encoding, leading to a file descriptor leak):
>
> https://issues.guix.gnu.org/issue/38857
> https://issues.guix.gnu.org/issue/38836
Commit f4cde9ac4aedb516c050a30fd999673da434bfa0 fixes it for good it
seems! (You can monitor /proc/PID/fd while ‘guix refresh’ or ‘guix
import crate -r’ is running. :-))
There was also a CRAN-specific FD leak fixed in
af0aefd8c10701fa32341506e36297e5105f6143.
Let me know is anything is amiss!
Ludo’.
--- End Message ---