[Twisted-Python] Five Crazy Ideas to Start Your Week

[Glyph Lefkowitz]

On Tue, 8 Oct 2002 20:08:14 +0300, Tommi Virtanen <tv at twistedmatrix.com> wrote:
> On Tue, Oct 08, 2002 at 02:04:24AM -0500, Glyph Lefkowitz wrote:

> > These URLs need to be able to represent transport mechanism (TCP? UNIX socket?
> > SSL? Weird firewall-tunneling stuff?)

> 	"Talk to subprocess that runs this command to connect to the other end"
> 	("ssh remotehost pbserver", "ssh remotehost
> 	connect-stdinout-to-unix-socket /path/socket")

> 	And yes, I may want that even after Twisted has a fully working
> 	SSH implementation. For rex :)

I don't quite get what you're talking about here.  You want the URLs to be
shell command-lines? :)

> 	I think you may want to look at SASL for ideas on
> 	authentication. It seems to be the standard way to add generic
> 	authentication support to a protocol these days.

>From what I can tell, it wouldn't work at all for PB.  From the RFC:

   In the case that a profile explicitly permits multiple successful SASL
   negotiations to occur, then in no case may multiple security layers be
   simultaneously in effect.  If a security layer is in effect and a subsequent
   SASL negotiation selects no security layer, the original security layer
   remains in effect.  If a security layer is in effect and a subsequent SASL
   negotiation selects a second security layer, then the second security layer
   replaces the first.

I understand that there are considerations where authentication is bound up in
link-layer security (public key crypto) but for most cases I'd like to keep
them separate so you can authenticate to multiple objects requiring different
authentication conversations in the same session.

> >     pb://pyramid/service#perspective

> 	What part talks about TCP/UNIX/etc? service? Then it needs more
> 	structure to it.

Same as with HTTP:
    pb://pyramid/service == pb-tcp://pyramid/service
    pb-ssl://pyramid/service
    pb-unix:/foo/bar://service

> >     pb://pyramid/identity:password@service#perspective

> 	Eww. Passwords in URLs is baaad. Because users like to enter URLs on
> 	command line.

> 	I'd much rather see an explicit "--password-file filename" and
> 	"--password-fd n".

Yes, and smart users will use that, for the most part.  Still, you need a way
to represent simple authentication as part of a URL.  Sometimes the URLs
themselves will be secret and the authentication information will be a swiss
number or something.  E does everything through exchange of URLs, and it's
pretty secure.

> > Public-key authentication mechanism, using the same identity name.  Connection
> > over SSH transport (sshkey auth only available this way).
> > 
> >     pb-ssl://pyramid/cert$identity@service#perspective
> > 
> > PB over SSL, using certificate auth.
> > 
> >     pb://pyramid/this/that/the-other/my-service#perspective

> 	Hmm. Idea. Allow one to specify when the server is trusted.  "Connect
> 	to server X if its public key has fingerprint F."  http://www.fs.net/

Any proposals for how to implement that?

> > [ ... ]

> >     - <img /> or <object /> tags that automatically download other items, which
> >       may be webpages containing javascript.
> > 
> > Again, don't allow these tags.  Or, have the server-side site download the
> > images and verify that they are PNGs (alternately also doing PIL stuff to
> > remove steganographic information, if you're _really_ paranoid).
> 
> 	Your basic problem here is that you are trying to disallow
> 	things you know are not safe. That assumes you are omnipotent.
                                                           ^

I assume you mean "omniscient".  If I were omnipotent, I would smite skript
kiddies with lightning from the sky, and forget about all this software-level
security :)

> 	While not contesting that, I still feel the only sane architecture is
> 	to catalogue known safe things, and only allow those. Something like a
> 	DTD/schema should do the job.

Okay, you have a point.  Still, it is useful to know which are potentially
problematic so that we can allow the usage of things like IMG with appropriate
warnings and links that remove session privileges first.

> > Even if I managed to get this right for the web, though, trying to avoid lock
> > in to the web's way of thinking about forms is very tricky!  I have yet to
> > seriously think about how GTK, PyUI, or Tkinter would work with this.  I have
> > spent a little while thinking about how a text-based virtual world interface in
> > twisted reality, though, and that should be pretty easy (building a machine
> > with dials, knobs, etc, and a big button for "submit").
> 
> 	IMHO, form-based GUIs suck horribly. A GUI is good only if
> 	it is interactive -- dynamic in some way. Most of the current
> 	GUIs only try to reach rich with forms that change
> 	dynamically.

> 	Have you ever used mc-foo fan? While certainly not the greatest GUI in
> 	the world, imagine you had to use it through forms.

Some GUIs simply don't work with forms.

On the other hand, there's a large class of GUI that does.  In fact some might
say that most of the GUIs in the world are form-based.  If forms couldn't
represent a large number of things that people want to do when interacting with
a computer, then the web would have died an early death.

> > squatting.  I think that by having a distributed naming system (where different
> > people call the "python" group different things, but python at twistedmatrix.com
> > will always get you to the one you're looking for) might circumvent squatting.

> 	So user A will see python at python.org as "python", user B will see
> 	python at twistedmatrix.com as "python", and if those two ever have to be
> 	squashed to the same namespace, user A will see "python
> 	(python at python.org)" and "python at twistedmatrix.com" and user B will see
> 	"python at python.org" and "python (python at twistedmatrix.com)"?

This is how e-mail naming works, isn't it?  User A is connecting to python.org,
user B is connecting to twistedmatrix.com.  The difference is that hosts may
provide either redirects for a certain name between each other, or relays for a
particular channel (a-la ry).

> 	This problem may be easier to think of in terms of nicks than of
> 	channels; IIRC there was some chat system that under the hood
> 	identified users with user at host (unix user id / email, whatever), but
> 	allowed them to set their list of "preferred nicknames".  User A would
> 	see user B with the first available preferred nickname from B's list,
> 	or as userB at hostB if none was available. And this was, IIRC, done fully
> 	in A's client; if B and C saw different people (were on different
> 	channels), they could see A with a different nickname.

This is an interesting idea, but it has the potential to be pretty confusing, I
think.  Tacking on an implicit domain name to channel/user names is a
convenience, but shifting around the displayed name is potentially even more
confusing.  (At least: as I understand it, I was thinking the user would type
"join python" and get a window that says "python at twistedmatrix.com"; what
you're suggesting is that the user types "join python at twistedmatrix.com" and
gets a window that says "Arglebargle!" because that is the python group's
preferred nickname? )

Thanks for the response.


-- 
 |    <`'>    |  Glyph Lefkowitz: Traveling Sorcerer   |
 |   < _/ >   |  Lead Developer,  the Twisted project  |
 |  < ___/ >  |      http://www.twistedmatrix.com      |