When emerging realplayer it can not be established a ssl connection to the server helixcommunity.org Reproducible: Always Steps to Reproduce: 1. $ USE="nsplugin" emerge realplayer Actual Results: Calculating dependencies ...done! >>> emerge (1 of 1) media-video/realplayer-10.0.5 to / >>> Downloading https://helixcommunity.org/download.php/1343/RealPlayer-10.0.5.756-20050513.i586.rpm --18:45:13-- https://helixcommunity.org/download.php/1343/RealPlayer-10.0.5.756-20050513.i586.rpm => `/usr/portage/distfiles/RealPlayer-10.0.5.756-20050513.i586.rpm' Resolving helixcommunity.org... 207.188.25.135 Connecting to helixcommunity.org|207.188.25.135|:443... connected. ERROR: Certificate verification error for helixcommunity.org: unable to get local issuer certificate To connect to helixcommunity.org insecurely, use `--no-check-certificate'. Unable to establish SSL connection. !!! Couldn't download RealPlayer-10.0.5.756-20050513.i586.rpm. Aborting. I solved the problem by using: wget --no-check-certificate https://helixcommunity.org/download.php/1343/RealPlayer-10.0.5.756-20050513.i586.rpm and then moving the file to /usr/portage/distfiles My emerge info: Portage 2.0.51.22-r2 (default-linux/x86/2005.0, gcc-3.4.4, glibc-2.3.5-r1, 2.6.7-gentoo-r14 i686) ================================================================= System uname: 2.6.7-gentoo-r14 i686 Intel(R) Pentium(R) 4 Mobile CPU 1.90GHz Gentoo Base System version 1.6.13 distcc 2.5 i586-pc-linux-gnu (protocol 1) (default port 3632) [disabled] ccache version 2.2 [disabled] dev-lang/python: 2.2.3-r5, 2.3.4, 2.4.1-r1 sys-apps/sandbox: 1.2.8 sys-devel/autoconf: 2.13, 2.59-r7 sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6 sys-devel/binutils: 2.16.1 sys-devel/libtool: 1.5.18-r1 virtual/os-headers: 2.6.11-r2 ACCEPT_KEYWORDS="x86 ~x86" AUTOCLEAN="yes" CBUILD="i686-pc-linux-gnu" CFLAGS="-O3 -march=pentium4 -pipe -fomit-frame-pointer" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc /opt/tomcat/conf /usr/X11R6/lib/X11/xkb /usr/kde/2/share/config /usr/kde/3.4/env /usr/kde/3.4/share/config /usr/kde/3.4/shutdown /usr/kde/3/share/config /usr/share/config /usr/share/texmf/tex/generic/config/ /usr/share/texmf/tex/platex/config/ /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d" CXXFLAGS="-O3 -march=pentium4 -pipe -fomit-frame-pointer" DISTDIR="/usr/portage/distfiles" FEATURES="autoconfig distlocks sandbox sfperms strict" GENTOO_MIRRORS="http://distfiles.gentoo.org http://distro.ibiblio.org/pub/Linux/distributions/gentoo" LANG="en_US" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="x86 X alsa apm arts avi bash-completion berkdb bitmap-fonts bonobo cdr crypt cscope cups curl emboss encode esd f77 fam flac foomaticdb fortran gdbm gif gnome gphoto2 gpm gstreamer gtk gtk2 gtkhtml guile imagemagick imlib ipv6 java jpeg kde ldap libg++ libwww mad mikmod motif mp3 mpeg mysql ncurses nls odbc ogg oggvorbis opengl oss pam pdflib perl png python qt quicktime readline samba sdl slang spell sse ssl svga tcltk tcpd tetex tiff truetype truetype-fonts type1-fonts vorbis xine xml xml2 xmms xv zlib userland_GNU kernel_linux elibc_glibc" Unset: ASFLAGS, CTARGET, LC_ALL, LDFLAGS, LINGUAS, MAKEOPTS, PORTDIR_OVERLAY
This seems to be a problem with the default wget command, not sure if there's a clean solution about this. Portage devs, what do you think?
Works just fine here.
I am able to reproduce the problem with wget-1.10 but wget-1.9.1-r5 works fine. Note that you can copy the FETCHCOMMAND and RESUMECOMMAND from make.globals and modify them in make.conf but that is not recommended for this particular problem.
This seems to happen whenever the server uses a self-signed certificate. The same error occurs with https://bugs.gentoo.org/. However, adding the parameter to the default configuration will likely break wget-1.9. Is it possible to patch wget to disable the issuer check by default?
(In reply to comment #3) > I am able to reproduce the problem with wget-1.10 but wget-1.9.1-r5 works fine. I am using wget-1.10 with default configuration and cannot reproduce this.
Created attachment 65297 [details] emerge --info with broken wget-1.10 (In reply to comment #5) > I am using wget-1.10 with default configuration and cannot reproduce this. I have rebuilt wget-1.10 and I still get the same results with the default config. net-misc/wget-1.10 -build -debug +ipv6 +nls -socks5 +ssl -static
dev-java/jdictrayapi also suffers from this problem. Adding --no-check-certificate to FETCHCOMMAND solved this problem. [ebuild R ] net-misc/wget-1.10 -build -debug -ipv6 -nls -socks5 +ssl -static 3 kB
is there a reason a maintainer can not throw the file into distfile-local on tocun so servers will pick it up from there instread of trying to grab it from main site (seeding purpose)? I for one do not want to see --no-check-certificate add to default the user should have to accept the certificate ... worse case would be just to setup nomirrors in the ebuild pointing user to place to get file like a few of the java builds and other misc ebuilds are done.
dev-java/jdictrayapi is on the mirros I know http://distfiles.gentoo.org has it already and I am sure a few others out there do as well.
(In reply to comment #9) > dev-java/jdictrayapi is on the mirros I know http://distfiles.gentoo.org has it > already and I am sure a few others out there do as well Yeah. I should have written more the my first comment from my post to gentoo-dev. The problem comes whenever I have to version bump it. I have --no-check-certificate in my FETCHCOMMAND so it does not bother me any more. (In reply to comment #8) > is there a reason a maintainer can not throw the file into distfile-local on > tocun so servers will pick it up from there instread of trying to grab it from > main site (seeding purpose)? It is possible that there is/will be a package that we are not allowed to mirror and has to be downloaded from upstream (for example because of counters) and the download link is over ssl like this. > I for one do not want to see --no-check-certificate > add to default the user should have to accept the certificate ... worse case > would be just to setup nomirrors in the ebuild pointing user to place to get > file like a few of the java builds and other misc ebuilds are done. --no-check-certificate doesn't ask anything from the user. At least not here. I just checked man wget and there is a log of good information about the option.
(In reply to comment #8) > is there a reason a maintainer can not throw the file into distfile-local on > tocun so servers will pick it up from there instread of trying to grab it > from main site (seeding purpose)? Definitely another solution. > I for one do not want to see --no-check-certificate add to default [. ] the > user should have to accept the certificate ... It seems that previous versions of wget did not check the issuer at all, so adding it to defaults would not give any worse behaviour than before. Self-signed certificates are not uncommon at all in the open-source world given that issuers charge big dollars. > worse case would be just to setup nomirrors in the ebuild pointing user to > place to get file like a few of the java builds and other misc ebuilds are > done. Definitely worst case. ;) While I think it is preferable that certificates aren't verified when portage is using wget, adding the option to the default FETCHCOMMAND will likely break earlier versions of wget. However, modifying wget's default configuration also brings the issue of users using wget outside of portage and having certificates not checked when they should be. Hence, the two solutions above really do seem like the only way out.
I tried earlier versions and it seems that they do fail with the --no-check-certificate option. What about installing a wrapper in for example /usr/lib/portage/bin and make sure that it comes in $PATH before the actual wget? The wrapper would just call /usr/bin/wget --no-check-certificate. This way wget normally functions as wanted but with portage it would not check the certificates.
wget-1.10 here and fails unless I'm using the --no-check-certificate option.
solar, spanky, can I get your opinions on this? Brian, Jason, you guys?
Created attachment 68312 [details, diff] wget-no-cert-check-for-portage.patch how about this ?
The certificate check can be disabled in wgetrc: checkcertificate = off maybe just adding that to portage's home ~/.wgetrc can help, but I'm not sure about how that is handled by older version then.
*** Bug 107317 has been marked as a duplicate of this bug. ***
*** Bug 108016 has been marked as a duplicate of this bug. ***
*** Bug 110735 has been marked as a duplicate of this bug. ***
*** Bug 112128 has been marked as a duplicate of this bug. ***
Got to disagree here: First, it's not self-signed. At least according to Konqueror, it's signed by some company called "Equifax", which has a website at http://equifax.com Second, the problem is that it can't verify the site's cert because it doesn't know about the Equifax CA, which should be in /etc/ssl/certs for the check to work. The appropiate cert is in the ca-certificates package, and installing it fixes this problem. I already suggested this solution in bug #112128 Third, I think that from the security perspective it's an extremely bad idea to ignore bad certificates. Why use SSL at all, then? IMO, the problem is not wget, but that the default contents of /etc/ssl/certs don't include the required CA certificate, which makes verifying the site's cert impossible.
(In reply to comment #21) > Third, I think that from the security perspective it's an extremely bad idea to > ignore bad certificates. Why use SSL at all, then? Because there's no other option with that damned realplayer thing? :=) SSL does not matter here in the least, we check the file integrity via digests, if that's downloaded via SSL or not is irrelevant.
Being a bit pedantic here, but those are different things. Digests assure that the downloaded information was transferred correctly and wasn't corrupted by some kind of network/disk/etc problem. What SSL does is to provide encryption, and some level of trust. At least according to Equifax, helixcommunity.com is who they say they are. Then, it's probably not particularly useful for a media player, and gpg signatures would be a much better solution as well.
(In reply to comment #23) > > Digests assure that the downloaded information was transferred correctly and > wasn't corrupted by some kind of network/disk/etc problem. > They ensure that the user has exactly the same file as the developer who committed the ebuild. > > What SSL does is to provide encryption, and some level of trust. At least > according to Equifax, helixcommunity.com is who they say they are. Then, it's > probably not particularly useful for a media player, and gpg signatures would > be a much better solution as well. It is up to the developer committing the ebuild to make sure that the tarball he used was valid. And by the way the Manifests can already be signed by developers using gpg. It is just not mandatory yet.
> They ensure that the user has exactly the same file as the developer who > committed the ebuild. No, they don't. They ensure that the user has the same file from which the digest was generated. Technically, nothing stops somebody with access to a gentoo rsync mirror from taking a tarball, putting a trojan in it, and regenerating the m5sum. Putting a signature around the manifest, or the source file itself would fix the problem nicely though. I see that some manifests indeed do have a signature. Now, back to the original discussion, IMO, if something is only available from a SSL page, it's an extremely bad idea to subvert the whole point of SSL (especially for the whole system), when a perfectly workable solution is to just include the required certificate.
(In reply to comment #25) > No, they don't. They ensure that the user has the same file from which the > digest was generated. Technically, nothing stops somebody with access to a > gentoo rsync mirror from taking a tarball, putting a trojan in it, and > regenerating the m5sum. Ah, now this debate starts to be really remarkable because this whole bug is about an ebuild which has RESTRICT="nomirror"; so now you will for sure enlighten us how you'll modify that upstream rpm to match the digests/manifests on Gentoo mirrors, won't you? ;-) > Now, back to the original discussion, IMO, if something is only available from > a SSL page, it's an extremely bad idea to subvert the whole point of SSL > (especially for the whole system), when a perfectly workable solution is to > just include the required certificate. SSL does not ensure anything, if you don't trust the authority that has issued the cerfificates. I've never heard about Equifax CA and hence I don't care whether the certificate validates or not, it does not mean anything to me. And nothing guarantees that the particular CA will be included in ca-certificates package next time. So, to conclude this, the only way to ensure integrity is signing manifests with gpg signatures, which will hopefully be mandatory soon. And now we could perhaps move back towards solving this issue by either disabling the pointless certificate validation checks in wget or by putting nofetch restrict into the ebuild.
(In reply to comment #26) > Ah, now this debate starts to be really remarkable because this whole bug is > about an ebuild which has RESTRICT="nomirror"; so now you will for sure > enlighten us how you'll modify that upstream rpm to match the digests/manifests > on Gentoo mirrors, won't you? ;-) > This problem also affects dev-java/jdictrayapi but there are probably others too.
> Ah, now this debate starts to be really remarkable because this whole bug is > about an ebuild which has RESTRICT="nomirror"; so now you will for sure > enlighten us how you'll modify that upstream rpm to match the > digests/manifests on Gentoo mirrors, won't you? ;-) Well, it could technically be broken into, and have both rpm and digest replaced. IIRC, such a thing even happened before with some distribution, but I forget which. A gpg signature made with a good key is much harder to work around, as you can generate it on a secured computer with no internet connection, then copy the resulting signature to the server, and without the private key it can't be falsified. Also, I imagine RESTRICT="nomirror" is present on very few ebuilds, so the general point still stands. > SSL does not ensure anything, if you don't trust the authority that has > issued the cerfificates. Fair enough, I also think SSL is a somewhat flawed system, and gpg is a lot better for ebuilds. After all, ultimately your trust is into Microsoft or whoever decided which CAs to trust. On the other hand, you can't exactly expect people to go to key signing parties so that they verify their bank's signature. Still, I stand by what I said: SSL does have a function (even if it's not perfect), and it seems to me it's a much better to add a cert for Equifax than to ignore all sanity checking for everything. At least by adding the cert you're only making an exception for Equifax, instead of subverting SSL for everything at once. Say, I could see SSL having some use for some company's package mirror, so the fact that this particular instance of it is a bit inconvenient shouldn't be a reason to break it for everything.
*** Bug 113101 has been marked as a duplicate of this bug. ***
*** Bug 113254 has been marked as a duplicate of this bug. ***
Uhm, like - can we have some solution? There have been quite a few mentioned here, so it would be nice to implement one of them instead of collecting duplicates of this bug.
IMO, the wrapper solution Petteri R
IMO, the wrapper solution Petteri Räty has suggested is good enough. It is simple, will solve the emerge -f problem, and does not change upstream behaviour.
(In reply to comment #32) > IMO, the wrapper solution Petteri R
(In reply to comment #32) > IMO, the wrapper solution Petteri Räty has suggested is good enough. It is > simple, will solve the emerge -f problem, and does not change upstream behaviour. For this solution to work we also need to modify the FETCH and RESUMECOMMANDS variables in make.globals to be be dependant on PATH. /etc/make.globals:FETCHCOMMAND="/usr/bin/wget -t 5 --passive-ftp -P \${DISTDIR} \${URI}"
Hmm, pardon my ignorance wrt make.globals. Any problem with just adding --no-check-certificate to FETCHCOMMAND ?
(In reply to comment #34) > Hmm, pardon my ignorance wrt make.globals. Any problem with just adding > --no-check-certificate to FETCHCOMMAND ? Does not work with the current stable version.
(In reply to comment #35) > (In reply to comment #34) > > Hmm, pardon my ignorance wrt make.globals. Any problem with just adding > > --no-check-certificate to FETCHCOMMAND ? > > Does not work with the current stable version. Sorry. Older stable version.
If it works with current stable version do we care ?
(In reply to comment #37) > If it works with current stable version do we care ? And how would the users from older versions update when the FETCHCOMMAND does not work?
Put the newer wget in the DEPEND of the portage ebuild so that it get's updated first ?
*** Bug 113873 has been marked as a duplicate of this bug. ***
*** Bug 113999 has been marked as a duplicate of this bug. ***
*** Bug 114495 has been marked as a duplicate of this bug. ***
*** Bug 116147 has been marked as a duplicate of this bug. ***
This bug has been hanging around for over 4 months, pick up one solution and implement it, please... Meanwhile, at least someone finally fetch-restrict the damned realplayer ebuild. :/
*** Bug 116386 has been marked as a duplicate of this bug. ***
*** Bug 116455 has been marked as a duplicate of this bug. ***
*** Bug 116691 has been marked as a duplicate of this bug. ***
*** Bug 117094 has been marked as a duplicate of this bug. ***
*** Bug 117146 has been marked as a duplicate of this bug. ***
Sorry, beeing a bit acid but what the hell are you doin guys? The bug is still around and you mark it as solved? Or maybe you think that manually downlaoding the file and putting it in distfiles is a solution? Can i call it a temporary turnaround after 4 months?... Ok... here i was destructive... now trying to be constructive. In my opinion, there should be an optional variable to pass as parameters for wget, so ebuilds would look something like this: SRC_URI="https://... realplayer..." WGET_EXTRA_PARAMS="--no-check-certificate" Shouldn't be that hard to implement and would fix anything ONLY where required. David
(In reply to comment #50) > Sorry, beeing a bit acid but what the hell are you doin guys? The bug is still > around and you mark it as solved? do you have issues reading ? nowhere does it say this bug is marked solved, in fact it's still labeled "NEW" > In my opinion, there should be an optional variable to pass as parameters for > wget, so ebuilds would look something like this: or you can simply `emerge app-misc/ca-certificates` and watch while wget accepts the ssl cert from realplayer
> or you can simply `emerge app-misc/ca-certificates` and watch while wget > accepts the ssl cert from realplayer > Which is what I've been arguing for all along. Why make some new strange system, when then there are two much simpler solutions available? Solution 1: Add a build time dependency on app-misc/ca-certificates Solution 2: Make ca-certificates get installed by default, or add the Equifax cert to the default contents of /etc/ssl/certs
Created attachment 75807 [details, diff] realplayer-10.0.6.ebuild-ca-cert-depend.patch Is this acceptable? No need to bump, no need to patch the world+dog (wget/portage/andsoon)... Just put ca-certificates in DEPEND.
no, i'm looking at adding the ca-cert package to PDEPEND of openssl so everyone will get it by default
(In reply to comment #54) > no, i'm looking at adding the ca-cert package to PDEPEND of openssl so everyone > will get it by default > I don't think this bug will be fixed by adding that. The package can't possibly include every self signed certificate out there.
why dont you emerge the package and test before claiming it wont work ;)
(In reply to comment #56) > why dont you emerge the package and test before claiming it wont work ;) > betelgeuse@pena ~/foo $ wget https://bugs.gentoo.org/attachment.cgi?id=65297 --02:03:31-- https://bugs.gentoo.org/attachment.cgi?id=65297 => `attachment.cgi?id=65297' Resolving bugs.gentoo.org... 140.211.166.163 Connecting to bugs.gentoo.org|140.211.166.163|:443... connected. ERROR: Certificate verification error for bugs.gentoo.org: self signed certificate To connect to bugs.gentoo.org insecurely, use `--no-check-certificate'. Unable to establish SSL connection.
I have yet to see a duplicate about something else than the damned realplayer thing, so I'd pretty much say this bug will be fixed w/ ca-certificates.
your test is invalid the gentoo.org certs *are* self signed, thus the aborting is valid the realplayer certs are not self signed, they were signed by a CA whose certificate is in the ca-certs package we're not going to change the default of wget rejecting unverifiable certs, or to make it so portage accepts such certs
(In reply to comment #59) > your test is invalid > > the gentoo.org certs *are* self signed, thus the aborting is valid > > the realplayer certs are not self signed, they were signed by a CA whose > certificate is in the ca-certs package > The title of this bug is "wget-1.10 fails on ssl self-signed certificate". Yes, the realplayer issue is of course resolved by adding the certificates but it does not resolve the case with self-signed certificates.
which we arent going to "fix" as it isnt a bug
(In reply to comment #61) > which we arent going to "fix" as it isnt a bug > Well what are we going to do to ebuilds with RESTRICT="mirror" that need to be downloaded from a site with a self signed certificate? Such a case may not exists now but it is possible.
RESTRICT=fetch
I have never look at the source of an ebuild, but I believe the default action is 'wget' with some argument (the URL), and that seems tweakable since some ebuilds can use CVS or subversion. Even thought I never wrote any ebuild, I could see two solutions: - alter actual ebuild, and change the download/fetch command to an internal function that would something automatable ... - make actual ebuild depend on a new ebuild, not the ca-certificates, BUT create a brand new ebuild that would actually just do that download. The second way, you only alter dependency tree, and the direct consequence is that when portage come to check distfiles/*, the file is already here. The new ebuild shall only depend on wget, and not require and thing in distfiles/*, and the action would not ./configure && make, but wget --options-we-need. Please, there are many trivial way to solve this in 10mn, and this bug now looks like a Hurd mailing list. Really.
*** Bug 118088 has been marked as a duplicate of this bug. ***
openssl now depends on ca-cert pkg
*** Bug 118387 has been marked as a duplicate of this bug. ***
*** Bug 125363 has been marked as a duplicate of this bug. ***
I still see this problem as of now on ~x86. Did anyone commit these patches or what is the resolution except manual download of the file? # emerge realplayer Calculating dependencies... done! >>> Emerging (1 of 1) media-video/realplayer-10.0.6 to / >>> Downloading https://helixcommunity.org/download.php/1589/RealPlayer-10.0.6.776-20050915.i586.rpm --16:55:11-- https://helixcommunity.org/download.php/1589/RealPlayer-10.0.6.776-20050915.i586.rpm => `/usr/portage/distfiles/RealPlayer-10.0.6.776-20050915.i586.rpm' Resolving helixcommunity.org... 207.188.25.135 Connecting to helixcommunity.org|207.188.25.135|:443... connected. ERROR: Certificate verification error for helixcommunity.org: unable to get local issuer certificate To connect to helixcommunity.org insecurely, use `--no-check-certificate'. Unable to establish SSL connection. !!! Couldn't download RealPlayer-10.0.6.776-20050915.i586.rpm. Aborting. # cd /usr/portage/distfiles/ # wget --no-check-certificate https://helixcommunity.org/download.php/1589/RealPlayer-10.0.6.776-20050915.i586.rpm --16:55:25-- https://helixcommunity.org/download.php/1589/RealPlayer-10.0.6.776-20050915.i586.rpm => `RealPlayer-10.0.6.776-20050915.i586.rpm' Resolving helixcommunity.org... 207.188.25.135 Connecting to helixcommunity.org|207.188.25.135|:443... connected. WARNING: Certificate verification error for helixcommunity.org: unable to get local issuer certificate HTTP request sent, awaiting response... 200 OK Length: 6,643,315 (6.3M) [application/binary] 100%[==============================================================================================>] 6,643,315 436.89K/s ETA 00:00 16:55:42 (415.97 KB/s) - `RealPlayer-10.0.6.776-20050915.i586.rpm' saved [6643315/6643315] #
*** Bug 135389 has been marked as a duplicate of this bug. ***
*** Bug 144470 has been marked as a duplicate of this bug. ***
*** Bug 156057 has been marked as a duplicate of this bug. ***
