Mozilla supports telnet:// URLs on Windows and Mac OS 9 (see now Linux-only bug 33282). It would be nice if Mac OS X could launch telnet sessions in Terminal.app or the telnet client of choice. I don't know if this can be done through Internet Config or what.
NEW: Someone else mentioned this elsewhere, so its real.
Terminal.app won't take AppleEvents but it will parse a .term file. I'm attaching a minimal example that will open a connecttion to the machine 'www'. You'd want to save this with a temp name in a temp location then do an open event (in Carbon anyway, maybe you'd fork /usr/bin/open for the NS version) on the file. Terminal should open it and execute the content.
This will be obvious to some people, but passing telnet URLs to Terminal.app via .term files would present some security risks. A feature like this would have to be designed so that Mozilla, for example, wouldn't handle the URL telnet://mozilla.org+;+rm+-rf+. by running telnet mozilla.org ; rm -rf .
As of Mac OS X 10.1 (IIRC), Terminal.app does accept AppleEvents. You can check out it's AppleEvent dictionary using Script Editor and find that it has a "do script with command" command with AppleEvent class = 'core', AppleEvent code = 'dosc'. Since there's no Apple-supplied method of selecting a Telnet client, Mozilla could just default to using Terminal.app until there's a better method of selecting helper apps for various protocols beyond mail, web and news.
Actually, I saw this work in Chimera 0.5 test (bug 167118) in Mac OS X 10.2. I haven't had time to figure out which made it work (OS or browser). Can someone update this bug?
I'm marking this security-sensitive as a courtesy to Apple becasue it describes a vulnerability in Mac OS X.
Do you want to secure all bugs that talk about telnet: URLs in jaguar? You might want to lock down bug 167118 as well... I can't find it, but there is some bug where Darin and I discussed having some URL handlers like telnet do more chacter filtering. My general thinking was: if you implement a URL that is an interactive, human readable terminal service, then many control characters are by definition, illegal or unacceptable, so let's not transmit them. Probably what I am thinking is actually a generic implementation of what was blocked in troublesome gopher and ftp URL exploits.
Has anyone confirmed this problem w/ Mac OS X? I know this does NOT work in 10.1, so is this a 10.2 only bug? And has anyone checked IE? I've contacted some people I know at Apple to find out what they think.
What exactly is the bug here? As far as I can tell this bug is talking about a potential enhancement, not something that currently exists in Mozilla. If so, this bug should be made public.
moving neeti's futured bugs for triaging.
Robert: It was my understanding that the problem described in comment 4 exists currently, but if I'm wrong, then this bug can be made public.
I reported the problem to Apple, and they wrote me back and said to look at: http://www.info.apple.com/kbnum/n120150 I'm still trying to follow up and find out a bit more about how this was okay in Mac OS 10.1 but broken in 10.2 (initial). What I'm really wondering is if there are differences between .term and telnet:// in how they are handled. It doesn't necessarily sound like the same problem, although the results could be similar security problems.
The security update referenced in comment 13 fixed the problem. However, there are probably a few unpatched systems out there.
My understanding is that we currently don't support telnet: URLs in Mac OSX. Is that correct?
That is not correct. Any protocol we don't handle internally gets passed off via the external handler mechanism and Mac OS X is more than happy to open a telnet:// URL in terminal.app. (/me didn't look at the source to see if we're trying to be smart and check for telnet: before dispatching though)
Yeah, so to clarify. Mac OS X 10.0.x and 10.1.x did not seem to register Terminal.app as the telnet URL handler. Mac OS X 10.2 does, although I was hoping to find a utility or line command that displays this mapping.
So how many unpatched 1.2 systems are out there? Does Apple push these updates out aggressively?
saari, Simon, could you please bring this up at the next mac-dev meeting, and try to come up with a solution that addresses the problem in OS 10.1 (apparently the problem ahs been fixed in 10.2, but we should protect 10.1 users)
Making this bug public since there's a fix (upgrade Mac OS). We should mention that in a release note.
RESOLVED/WFM: Mozilla 1.3b Mach-O, Chimera 0.6 I still don't know what made this start working, but I'm not going to wait for an answer. Hopefully they are spending their time making iChat and aim: handler.