As reported in bug #344495, recent github switch to https causes download problems with the current version of wget. The bug has been reported upstream (the report linked in the 'URL' field), and a fix has been committed. However, there was no release since and thus the issue still applies to all Gentoo users, causing trouble with all packages with downloads originating from github. Thus, I suggest either convincing upstream to make a release, making a snapshot or backporting the patches to the current version.
This is because of --no-check-certificate, right? Could you attach a build log where this fails?
Created attachment 253901 [details] Failing build log Sure. Here you are. Mirroring fails to catch it too. Thus, I am currently feeding the mirrors using distfiles-local but I don't think that's a good long-term solution.
openssl s_client -connect github.com:443 CONNECTED(00000003) depth=3 L = ValiCert Validation Network, O = "ValiCert, Inc.", OU = ValiCert Class 2 Policy Validation Authority, CN = http://www.valicert.com/, emailAddress = info@valicert.com verify error:num=19:self signed certificate in certificate chain verify return:0 --- Certificate chain 0 s:/O=*.github.com/OU=Domain Control Validated/CN=*.github.com i:/C=US/ST=Arizona/L=Scottsdale/O=GoDaddy.com, Inc./OU=http://certificates.godaddy.com/repository/CN=Go Daddy Secure Certification Authority/serialNumber=07969287 1 s:/C=US/ST=Arizona/L=Scottsdale/O=GoDaddy.com, Inc./OU=http://certificates.godaddy.com/repository/CN=Go Daddy Secure Certification Authority/serialNumber=07969287 i:/C=US/O=The Go Daddy Group, Inc./OU=Go Daddy Class 2 Certification Authority 2 s:/C=US/O=The Go Daddy Group, Inc./OU=Go Daddy Class 2 Certification Authority i:/L=ValiCert Validation Network/O=ValiCert, Inc./OU=ValiCert Class 2 Policy Validation Authority/CN=http://www.valicert.com//emailAddress=info@valicert.com 3 s:/L=ValiCert Validation Network/O=ValiCert, Inc./OU=ValiCert Class 2 Policy Validation Authority/CN=http://www.valicert.com//emailAddress=info@valicert.com i:/L=ValiCert Validation Network/O=ValiCert, Inc./OU=ValiCert Class 2 Policy Validation Authority/CN=http://www.valicert.com//emailAddress=info@valicert.com .... subject=/O=*.github.com/OU=Domain Control Validated/CN=*.github.com issuer=/C=US/ST=Arizona/L=Scottsdale/O=GoDaddy.com, Inc./OU=http://certificates.godaddy.com/repository/CN=Go Daddy Secure Certification Authority/serialNumber=07969287 Besides having a self-signed cert in the certificate chain, the certificate has CN=*.github.com while the server name is github.com. This seems to me to be a bad configuration on github.com - so it's up to them to fix it.
You can work around the problem by setting the certificate as trusted locally, of course.
(In reply to comment #4) > You can work around the problem by setting the certificate as trusted locally, > of course. Yeah but the problem is not me but users. I don't want them to have trouble downloading my packages because of known & fixed wget bug (as github states it is). And I certainly don't want to force users to use our mirrors.
(In reply to comment #3) .... > Besides having a self-signed cert in the certificate chain, the certificate has > CN=*.github.com while the server name is github.com. This seems to me to be a > bad configuration on github.com - so it's up to them to fix it. (In reply to comment #5) > (In reply to comment #4) > > You can work around the problem by setting the certificate as trusted locally, > > of course. > > Yeah but the problem is not me but users. I don't want them to have trouble > downloading my packages because of known & fixed wget bug (as github states it > is). And I certainly don't want to force users to use our mirrors. If you read my above comment, I don't see where there's a wget bug. The github certificate isn't appropriate for the hostname and wget seems to be strict in the validation check - that is a sane implementation.
*** Bug 346273 has been marked as a duplicate of this bug. ***
(In reply to comment #6) > If you read my above comment, I don't see where there's a wget bug. The github > certificate isn't appropriate for the hostname and wget seems to be strict in > the validation check - that is a sane implementation. The certificate *is* appropriate for the hostname, and all major browser implementations accept this certificate as valid. If you check the "Certificate Subject Alt Name" field of the certificate extensions you'll notice DNS entries for *.github.com and github.com. wget is not properly checking this field, and this is what the upstream bug fix fixes. Assigning this to base-system so this can be fixed ASAP.
Created attachment 255463 [details, diff] wget-sae.patch be useful to provide some useful pointers to upstream that actually fix your problem and you've tested ... based on the vague info in the upstream reports, try this commit
(In reply to comment #9) > based on the vague info in the upstream reports, try this commit Yep, wget now downloads the file correctly, without any complaints.
added to wget-1.12-r3 then ... thanks for testing
(In reply to comment #9) Your patched wget also fixes my problem in bug #346273. Thanks!
*** Bug 348470 has been marked as a duplicate of this bug. ***
*** Bug 349072 has been marked as a duplicate of this bug. ***
*** Bug 349244 has been marked as a duplicate of this bug. ***
