Hacker News Reader

Comment by astrodust | Hacker News Reader

Yeah, and I've used that exactly never. Whew.

I did a quick scan of libfetch (fetch(3)) and it seems clean. Thats sort of interesting to me because I've wondered for some time why ftp does not actually use libfetch. Can't say whether ftp not sharing the libfetch code is good or bad, in this case.

I've wondered for some time why ftp does not actually use libfetch

Because ftp(1) was written long before libfetch(3), and nobody wanted to rewrite it.

Why would this be down-voted? I take it you are not supposed to wonder or ask anything on HN?

If not, looks like the mods need to hand out some infractions to these down-vote happy morons.

Not to mention, use it for HTTP...

I bet a huge number of the population who has used the FTP client has never used it for HTTP because... using an FTP client for HTTP just doesn't make sense.

In OpenBSD the ftp(1) program /is/ the cli http client for the base system. wget is available in ports but not install by default. FreeBSD is probably similar

The wget-like utility present in the FreeBSD base system is fetch(1). It is a cli for the underlying libfetch, which provides HTTP/FTP client functions, and is used behind the scenes in a lot of places in the FreeBSD base, notably by all the package manager and ports systems.

The vulnerable ftp we're talking about here is a completely distinct piece of software, which is generally used only when you want to interactively browse a ftp server. But it doesn't seem to be related much to fetch(1). It has obviously common origins with the OpenBSD one, but I can't comment on how vulnerable the OpenBSD version is.

As an aside, this bug was fixed in OpenBSD's ftp(1) 5 years ago.

http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/usr.bin/ftp/fet...

http://marc.info/?l=openbsd-cvs&m=125128957525639&w=2

Reply on news.ycombinator.com