[Bug 931] Allow ssh-connections through a HTTP proxy (such as squid).

[bugzilla-daemon at mindrot.org]

http://bugzilla.mindrot.org/show_bug.cgi?id=931





------- Additional Comments From andreas.krueger at famsik.de  2004-09-18 21:42 -------
> Why should ssh have code to operate over HTTP proxies ...?

Convenience for its users.

If the ssh authors agree with me:

* There are many HTTP-Proxies out there, so

* enough users could make good use of the feature under discussion, and

* it is easy enough to implement it, without introducing bugs (or at least no
security-related bugs),

then the authors may want to choose to support it within ssh proper.  Which is
exactly what I propose.


> telnet proxies, and [fill-in-the-blank]

I agree with you. Ssh should not try to support all protocols known under the sun.

When the ssh authors think a particular protocol is of minor use to the ssh user
community at large, those few users that would want to use it may well be
burdened with the extra hassle of integrate external software.

Similar things might be said for protocols that are deemed sufficiently hard to
implement flawlessly.

> http://www.taiyo.co.jp/~gotoh/ssh/connect.html

That is an option. Still, I think implementing the feature I request would
enhance the situation, from a typical ssh user's perspective.

Of course, with a package such as ssh, secrity is an important issue for its users.

Personally, I have an extended previous history with, and a certain amount of
trust in, that particular Linux distribution (Debian, im my case), from which I
obtained my ssh installation.

Using external software such as the one you propose, from a source that I have
no previous relation with, is, to me, a somewhat different story.  It may well
be wonderful software. Yet I find myself considering to spend a certain amount
of time reviewing its source. In that sense, it's an expensive software (from my
point of view). If unfairly viewed as a programm to solely get the particular
HTTP job done I need, it is deplorably inefficient. This should never take
almost 3000 lines of code.

Also, for the particular software you propose, there is no bug tracking
database, such as this one. In my opinion, this does not shed a good light.
Neither does the author's decision to pack that much code into a single file. At
least, the revision history available informs us about previous bugs the
software had, which is good.

So, to sum it up: That external software you propose, definitely an option an
probably well worth being considered, does not seem to come out quite on the
same high level as this project does.



------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.