Subject: Re: bug#38857: X.509 certificate of 'crates.io' could not be verified during a recursive import from crates.io

From: Martin Becze <[email-masked]>
Date: Thu, 2 Jan 2020 14:37:52 -0500

I have had this problem as well. I noticed that the file descriptors 
where not being closed when the connections end. I think this is causing 
the issue. Related https://debbugs.gnu.org/cgi/bugreport.cgi?bug=20145

On 1/2/20 2:20 PM, Valentin Ignatev wrote:
> I don't think that it's related, but who knows. I only have a
> certificate issue when I'm using recursive crates import. I am able to
> import packages from crates one by one without an issue as well as
> doing other tls-sensitive stuff.
>
> Regards,
> Valentin
>
> On 1/2/20, Bengt Richter <[email-masked]> wrote:
>> Hi Guix,
>>
>> On +2020-01-02 09:12:43 +0200, Efraim Flashner wrote:
>>> On Thu, Jan 02, 2020 at 01:45:35AM +0300, Valentin Ignatev wrote:
>>>> Hi! I'm trying to recursively import a package from crates.io like
>>>> this:
>>>>
>>>> guix import crate [email-masked] --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
>>> I've had it happen to me also sometimes. It's like it forgets that it
>>> just successfully connected 100+ times and then fails.
>>>
>>>
>>> --
>>> Efraim Flashner   <[email-masked]>   אפרים פלשנר
>>> GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
>>> Confidentiality cannot be guaranteed on emails sent or received
>>> unencrypted
>> I don't know if this could be related, but...
>> I am also running guix on Archlinux and experienced a TLS problem
>> after doing pacman -Syu.
>>
>> Mutt got updated and I could no longer get my pop mail.
>> I reverted the last mutt update:
>>
>> --8<---------------cut here---------------start------------->8---
>> [2020-01-01T15:53:13-0800] [ALPM] downgraded mutt (1.13.2-1 -> 1.12.2-1)
>> --8<---------------cut here---------------end--------------->8---
>>
>> And am writing this with the reverted verssion.
>> (So BTW this may be a heads-up not to package 1.13.2-1 until the problem
>> is resolved, to avoid similar breakage for other Arch users, and perhaps
>> others?)
>>
>> BTW2, if you are using pacman on arch, this little snippet is handy to list
>> what your last pacman {up,down}grade did:
>>
>> I do listing variants as ls-whatever -- this one is ls-pacupd:
>> --8<---------------cut here---------------start------------->8---
>> #!/usr/bin/bash
>> # ~/bin/ls-pacupd -- list latest pacman Syu upgrades
>> latest="$(stat -c '%y' /var/log/pacman.log|cut -d ' ' -f1)"
>> egrep "$latest.* (up|down)graded " /var/log/pacman.log
>> --8<---------------cut here---------------end--------------->8---
>>
>> I found that the guix-installed  version of mutt worked for getting mail,
>> and saw that it used the prior version.
>>
>> However, emacs is mutt's configured editor, and after some longish time
>> editing
>> the entire system would freeze and not respond to ANY key input, and I had
>> to
>> power down physically (5-sec press of power button).
>> So I had to go back to the old Arch version.
>>
>> I am still mystified by this freeze-up. It's possible that I am typing some
>> fatal
>> combination of keys on this keyboard or that my migration from a dying
>> laptop to
>> an SSD in a USB3 cassette booted with UEFI on a Lenovo Swift did not
>> entirely succeed.
>>
>> My context:
>>
>> I am running on tty1 with guix "disabled" by not setting up its paths etc
>> in
>> ~/.bash_profile at login, so this is my current boot context here:
>> ┌─────────────────────────────────────────────────────────────────────────────────┐
>> │ Booted at 2020-01-02 08:50 -0800 (PST) and logged in as as
>> bokr@Evo25c2ArchGx4  │
>> ├─────────────────────────────────────────────────────────────────────────────────┤
>> │ HW host:  Acer Swift SF113-31/ASAHI_AP_S, BIOS V1.08 11/22/2017
>>       │
>> │ MOUNTPOINT KNAME        LABEL            SIZE FSAVAIL FSUSE%
>>       │
>> │ /boot      sda1         Evo25c2EFI1        1G  461.9M    55%
>>       │
>> │ /          sda4         Evo25c2ArchGx4 167.9G   73.5G    50%
>>       │
>> │ Kernel: 5.4.6-arch3-1 #1 SMP PREEMPT Tue, 24 Dec 2019 04:36:53 +0000
>>       │
>> │    CPU: Intel(R) Pentium(R) CPU N4200 @ 1.10GHz
>>       │
>> └─────────────────────────────────────────────────────────────────────────────────┘
>>
>> Whereas on tty4 I logged in with a config value that my ~/.bash_profile
>> uses
>> to set MY_GUIX_MODE=enabled at the top and do further enabled/disabled
>> specializations
>> after that, so e.g. guix is found in $PATH and currently that makes
>> (captured on tty4 and and retrieved here on tty1)
>>
>> guix describe:
>> --8<---------------cut here---------------start------------->8---
>> Generation 27	Dec 29 2019 18:49:23	(current)
>>    guix 996182a
>>      repository URL: https://git.savannah.gnu.org/git/guix.git
>>      branch: master
>>      commit: 996182a84bafb4c4982dcb36c2c54b350c16629a
>> --8<---------------cut here---------------end--------------->8---
>>
>> Editing context in emacs here and now:
>> --8<---------------cut here---------------start------------->8---
>> pidparents      ?           8747 Ss   /usr/bin/bash
>> /home/bokr/bin/pidparents
>> emacs           tty1        2420 Sl+  emacs
>> /home/bokr/.mutt/temp/mutt-Evo25c2ArchGx4-1000-861-11810734661506241046
>> mutt            tty1         861 S    mutt
>> bash            tty1         461 Ss   -bash
>> login           ?            447 Ss   login -- bokr
>> systemd         ?              1 Ss   /sbin/init
>> \EFI\Evo25c2ArchGx4\vmlinuz-linux
>> --8<---------------cut here---------------end--------------->8---
>>
>> Regards,
>> Bengt Richter
>>
>
>