Subject: [sup-talk] mime-view hook

From: [email-masked] (Jon Dugan)
Date: Wed, 22 Apr 2009 18:11:40 -0700

I'm running the mainline sup from git.

I have a mime-view.rb hook like this:

case content_type
when "text/html"
    Redwood::log("w3m: " + '/opt/local/bin/w3m -dump -T ' + content_type + ' ' + filename)
    IO.popen('-') {|f| f ? f.read : exec('/opt/local/bin/w3m', '-dump', '-T', content_type, filename)}
else 
    Redwood::log("dumbplumb: " + filename)
    system '/Users/jdugan/projects/dumbplumb/dumbplumb', filename
end

It's supposed to render HTML in the SUP window and hand everything else off to
dumbplumb.  It does hand everything else off to dumbplub, however it doesn't
do what I expect for the HTML attachments.

Whatever gets returned from the hook should be displayed, right? 

I am a Ruby noob so maybe it's my Ruby that's bad.  (Although I've got a lot
of experience with Python, Perl, etc...)

If I send the output of the IO.popen to Redwood::log I see what I'd expect in
the log buffer, so I have confidence in the part that is using w3m to render
the HTML.

Why didn't I use backticks (`) instead of the calls to system and exec?
To sidestep shell quoting issues.  I started with backticks but attachments
with spaces and other shell meta characters were problematic.  

Thanks for any suggestions,

Jon

PS: dumbplumb may be of interest.  Here's the README:

dumbplumb is a simple mechanism for displaying files from remote systems
locally.  it is a brain dead hack that implements something which is something
like the Plan 9 plumber but not really.

Eventually it may be reworked to actually use the plan9 port plumber, but for
now it's just dumb.

dumbplumbd listens on port 9937 on your local system for requests.  dumbplumb
sends requests to dumbplumbd.  ssh port forwarding is used to proxy the two
together, eg:

ssh -R 9937:localhost:9937 remotehost

You can find dumbplumb at http://bitbucket.org/jdugan/dumbplumb/
-- 
Jon M. Dugan <jdugan at es.net>          | GTalk: jdugan.esnet
ESnet Network Engineering Group       | http://www.es.net/
Lawrence Berkeley National Laboratory | http://www.lbl.gov/

---

From: [email-masked] (William Morgan)
Date: Thu, 23 Apr 2009 05:47:59 -0700

Reformatted excerpts from Jon Dugan's message of 2009-04-22:
> It's supposed to render HTML in the SUP window and hand everything
> else off to dumbplumb.  It does hand everything else off to dumbplub,
> however it doesn't do what I expect for the HTML attachments.
> 

Not exactly. There are two MIME hooks, and you'll need them both for
what you're trying to do: mime-decode, for turning an attachment into
text (displayed directly in Sup), and mime-view, for launching
third-party applications to view an attachment. I've updated the docs on
these two in git to make their relationship a little more clear, but in
summary: mime-decode should return a string, or nil if uncovertable, and
mime-view should return true if the application was successful, and
false otherwise.

Note that by default Sup calls run-mailcap to view attachments it can't
convert to text, so you can make the dumbplumb behavior global by
changing your mailcap instead. (If you desire that.)

> dumbplumb is a simple mechanism for displaying files from remote
> systems locally.  it is a brain dead hack that implements something
> which is something like the Plan 9 plumber but not really.

That's awesome. Very useful for Sup.
-- 
William <wmorgan-sup at masanjin.net>

---

From: [email-masked] (Andrew Pimlott)
Date: Thu, 23 Apr 2009 10:53:36 -0700

> ssh -R 9937:localhost:9937 remotehost

You probably realize this, but...  A well-known port doesn't work for
this, because you need one plumber per display session.  So the SSH
forwarding needs to use the right plumber on this end and establish a
corresponding session on the other end.

The obvious model for this is SSH agent forwarding.  You'd have a
PLUMBER_SOCK variable containing the path to a unix socket, and ssh
would create a unix socket on the other end, forward it there, and set a
new PLUMBER_SOCK variable.  The obstacle is, the SSH developers haven't
shown any interest in making the SSH agent forward mechanism availble to
others.  See for example

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=294148

If you don't do this, you'll have plumbers stepping on each other, or
you'll have to manage ports manually.

Andrew

---

From: [email-masked] (Jon Dugan)
Date: Thu, 23 Apr 2009 11:14:48 -0700

> corresponding session on the other end.

That is definitely and issue and I should probably add that to the README.
However in practice it doesn't seem to be a problem for me, I only forward the
port for the first connection to my sup box.  When I leave a display I log out
of the sup box thus freeing the well known port for the next display I sit at.
(Or if I forget I can log in and kill that ssh process by hand.) However, this
whole fiasco is part of the reason I call it dumb.

There is also a significant security issue which is anyone on the sup box can
send a dumbplumb request if they know what port to talk to.  In my case this
is a fairly minor risk as I am the only person who uses my sup box.  This too
is part of the reason I call it dumb.

> you'll have to manage ports manually.

I've wanted this kind of forwarding for a long, long time.  I was unaware of
the patch listed there.  I'll have to take a look.  This would be especially
cool if it was forwardable like the agent socket, since sometimes I have to
ssh through intermediate boxes.  (But see my ssh-gw script for a cute trick
for getting around this:  http://bitbucket.org/jdugan/ssh-gw/).

The unix socket forwarding would make the whole thing much, much cleaner.

One hack to work around the port collision problem is to enable environment
variable forwarding (see SendEnv in ssh_config(5)) and use that to dynamically
choose a port per session.  This could be used to forward unix domain sockets
by combining this with something like socat.  This, however, starts to become
a huge tangle of duct tape and bailing wire...  Also SendEnv has some security
implications.

In short I'd love something less dumb, but for now this scratches an itch.

Jon

---

From: [email-masked] (Andrew Pimlott)
Date: Thu, 23 Apr 2009 15:59:13 -0700

> The unix socket forwarding would make the whole thing much, much cleaner.

It's sad that this hasn't been picked up.  I looked into it a while
back, and I can't remember exactly what the impediment is.  It would be
an extension to the SecSH protocol, and nobody on the ssh side seems to
get the need for it (baffling to me, given ssh-agent).  Even the code
that exists (AFAICT) only connects explicitly-named ports on either end.

> choose a port per session.

Even then, you're manually managing the ports:  You have to assign a
port number to every session you use; if others use the same machines
(which is unthinkable in the first place for lack of access control),
everyone's numbers have to be unique.  That's just dumb--but you know
that. :-)

> In short I'd love something less dumb, but for now this scratches an itch.

Credit to you for writing it.  As soon as I saw it, I knew the plumber
was the right thing, but when I ran into the forwarding problem, I gave
up.  I'm glad you didn't!

Andrew