* Fetching https://repos.j-schmitz.net/git/pub/squashed-portage.git ... git fetch https://repos.j-schmitz.net/git/pub/squashed-portage.git +HEAD:refs/git-r3/HEAD fatal: unable to access 'https://repos.j-schmitz.net/git/pub/squashed-portage.git/': SSL certificate problem: self signed certificate in certificate chain * ERROR: app-portage/squashed-portage-9999::last-hope failed (unpack phase): * Unable to fetch from any of EGIT_REPO_URI * * Call stack: * ebuild.sh, line 93: Called src_unpack * environment, line 3699: Called git-r3_src_unpack * environment, line 2195: Called git-r3_src_fetch * environment, line 2189: Called git-r3_fetch * environment, line 2112: Called die * The specific snippet of code: * [[ -n ${success} ]] || die "Unable to fetch from any of EGIT_REPO_URI"; This one is cacert based. This is a workaround. Could we somehow handle that from portage side? git config --global http.sslVerify false
I dunno. People are getting a bit touchy when it comes to SSL. Wasn't Gentoo already in 'we aim to treat cacert as trusted' party?
the cacert root crt is not installed on my system.
So it seems that Debian removed cacert lately. If you downgraded to ca-certificates-20130906, you'd notice that it works fine. I will have to investigate further if you want to override the check since it is done in libcurl, I'm afraid.
Oh, sorry, I just noticed that you provided a work-around. However, we will try to re-introduce cacert.
(In reply to Michał Górny from comment #4) > Oh, sorry, I just noticed that you provided a work-around. However, we will > try to re-introduce cacert. The workaround doesn't seem to work as the portage user's HOME is empty on emerge start. I added cacert into /usr/local/ so it works. But this is really just a workaround.
Well, the first question would be: is this a problem with your private ebuild or a public ebuild that's going to be hit by users? As for potential solutions, the best would be to somehow make the process locally able to trust cacert. Disabling SSL validation completely is pretty much equivalent to killing the SSL, so I'd rather not go that far. As for it, can't you just use plain http:// then?
(In reply to Michał Górny from comment #6) > Well, the first question would be: is this a problem with your private > ebuild or a public ebuild that's going to be hit by users? It is a public problem, as every cacert based connection will break. That specific ebuild is publicly available via layman. > As for potential solutions, the best would be to somehow make the process > locally able to trust cacert. Disabling SSL validation completely is pretty > much equivalent to killing the SSL, so I'd rather not go that far. As for > it, can't you just use plain http:// then? I can, but again this could also happen with other upstreams where we don't have access to the server. I would leave the bug open as a tracker and try to get cacert into gentoo instead.
After bug 504670 being fixed this should be also no problem anymore.
this is because the repos.j-schmitz.net domain is using CAcert: $ openssl s_client -host repos.j-schmitz.net -port 443 -CApath /etc/ssl/certs </dev/null >/dev/null depth=1 O = Root CA, OU = http://www.cacert.org, CN = CA Cert Signing Authority, emailAddress = support@cacert.org verify return:1 depth=0 CN = web.not-your-server.de verify return:1 DONE you should update the package to depend on ca-certificates[cacert(+)]
(In reply to SpanKY from comment #9) > this is because the repos.j-schmitz.net domain is using CAcert: > $ openssl s_client -host repos.j-schmitz.net -port 443 -CApath > /etc/ssl/certs </dev/null >/dev/null > depth=1 O = Root CA, OU = http://www.cacert.org, CN = CA Cert Signing > Authority, emailAddress = support@cacert.org > verify return:1 > depth=0 CN = web.not-your-server.de > verify return:1 > DONE > > you should update the package to depend on ca-certificates[cacert(+)] Exactly. But that report came before you fixed the dropped cacert in ca-certificates.
+ 21 Mar 2014; Justin Lecher <jlec@gentoo.org> squashed-portage-9999.ebuild: + Depend on cacert in ca-certificates, #504776 +
