On Tue, 5 Jun 2001, Jan Prikryl wrote:
>
> Yes, the SSL detection is broken on some systems. We are working on a
> fix.
>
Since wget is now a crypto application, I suggest extreme caution here.
On my system, only static SSL libraries exist. It bothers me greatly
that an attacker could corrupt a shared crypto library and, thus,
corrupt all crypto apps. Now your current testing uses rpath which is
irrelevant with static libs, but building with rpath is not benign
because that same attacker (or another one) could plant strange
libraries in the rpath location and wget could be compromised. I would
suggest either testing whether shared SSL libraries exist or providing
configure options so the user can choose.
>
> Could you provide an example? On my machine, GCC is in /usr/local/bin
> by default (I'm using the GCC 3.0 development version which has some
> bugs, so I prevent to keep tow versions of the compiler). In this
> setup, `CC=/usr/bin/gcc ./configure ... ; make' will build wget with
> the "old" GCC 2.95.2 just fine.
>
This is my error. I have a config.site script and a cc definition
crept in by mistake. I'm sorry that I bothered you with this.
In the midst of all this, I built wget with debugging and gcc turned up
these warnings:
rbuf.c:68: warning: implicit declaration of function `ssl_iread'
retr.c:122: warning: implicit declaration of function `ssl_iread'
gen_sslfunc.c:155: warning: implicit declaration of function `select_fd'
Some header files are not included and some are incomplete. Wget works
because the defaults happen to match the actual functions. It is not a
big deal though.
Thanks.
--
Jupiter
2001-06-06 19:07:22.660 UTC (JD 2452067.296790)
X = 0.631953667, Y = 4.648285018, Z = 1.977027736 (au)
X' = -0.007581252, Y' = 0.001124320, Z' = 0.000666516 (au/d)
