Can't update cache: invalid peer certificate contents: invalid peer certificate: UnknownIssuer about tealdeer HOT 15 OPEN

I'm having the same problem. I can curl it every time.
curl https://tldr.sh/assets/tldr.zip --output /tmp/tldr;
I can sometimes get the update to work but most of the time it won't

tldr --update
Error: Could not update cache

Caused by:
    0: error sending request for url (https://tldr.sh/assets/tldr.zip): error trying to connect: dns error: failed to lookup address information: Name does not resolve
    1: error trying to connect: dns error: failed to lookup address information: Name does not resolve
    2: dns error: failed to lookup address information: Name does not resolve
    3: failed to lookup address information: Name does not resolve

This is during a container build or from within the built container but is also true form my Ubuntu Linux WSL instance.
NOTE: We are behind a corporate proxy. Standard proxy vars are set including both uppercase and lowercase versions. No proxy authentication.

from tealdeer.

Hi, sorry for the long wait. We had a similar report recently in #328, but that ended up not being reproducible. Hearing "invalid certificates", I suspect that you have a build with bundled certificates that somehow got out of date or so. Can you reproduce this issue when using a fresh build from the main branch, possibly with different choice of feature flags?

from tealdeer.

About "we are behind a proxy": Are the two of you in the same company / network?

from tealdeer.

About "we are behind a proxy": Are the two of you in the same company / network?

Sorry, no, I don't think so. Not sure why I used the royal we there. :)

Github was having some service outages this morning, so that might have contributed.
I can now repeatedly update in a Linux box and I can run update the first time in a dev container based on rocky 9 however, running update a second time gives failed to lookup address information: Name does not resolve still.

from tealdeer.

But the "we" was not entirely false - I'm also behind a corporate proxy :) At least on the machine that has the issue. I will rebuild tealdeer with native-roots, webpki-roots and native-tls enabled after my holidays. But I'm wondering - Why are those features not enabled by default?

from tealdeer.

To build, exactly one of these features must be enabled. They map to equivalent features of the networking library we use. My current suspicion is that your builds have bundled certificates that are now somehow wrong / outdated, so a fresh build, depending on the feature, would use current system certificates or bundle a fresh set of certificates.

from tealdeer.

@sarg3nt your problem is unrelated to the certifcates, in your case DNS lookup fails. The first time / second time discrepancy is odd, not really sure what to make of that. In general, my suspicion would be that your system has some special DNS settings that our networking library is not picking up on. This would also explain why curl works. It doesn't really explain why tealdeer works sometimes 🤔 I am not sure right now how we should best pursue a resolution of this problem as it probably boils down to a library issue. I will come back to this later

from tealdeer.

I'm on Gentoo, so each time I reinstall the package it gets built from source (from your release tarball). I tried that already with no effect. The only thing left to try seems to be playing with some networking features.

from tealdeer.

@freijon Can you share the exact steps of your build?

from tealdeer.

Here you find the build recipe of the Gentoo tealdeer package: https://gitweb.gentoo.org/repo/proj/guru.git/tree/app-misc/tealdeer/tealdeer-1.6.1.ebuild

Only the default features are used, nothing special

from tealdeer.

I just built the package with webpki-roots - Same error.
Then I tried cargo build --release --features reqwest/native-tls --features native-roots - Success!

Can we do this by default?

from tealdeer.

Hm, this seems like an odd selection of features. The first is what you get if you build tealdeer with native-tls while the former uses non-native tls (rustls) and I think reqwest will just pick one of the two (this is also why you have to compile tealdeer with exactly one of the three feature flags).

I think that even though you rebuild the package on Gentoo, it will use our lockfile that maybe contains outdated certificates? By running cargo build yourself (without --locked), you avoid the lockfile. This still leaves the question why your own build with webpki-roots failed... Maybe the dependency was then cached and your build reused it? Not entirely sure to be honest. I would also expect the default feature, which is native-roots, to keep working since that is their entire purpose 🤔

from tealdeer.

@sarg3nt Did your problem ever re-occur?

from tealdeer.

@sarg3nt Did your problem ever re-occur?

Nope.

from tealdeer.