[Twisted-Python] SSHSessionProcessProtocol.inConnectionLost() behavior and Git over Conch

Michael Hudson-Doyle micahel at gmail.com
Thu Mar 4 21:51:09 MST 2010


On 4 March 2010 17:46, Bo Shi <bs1984 at gmail.com> wrote:
> Hi All,
>
> I've been struggling with this issue off and on for the better part of
> a month now.  Having implemented a simple git SSH server using some of
> the Conch examples in the official documentation, I encountered an
> issue that would cause a git client to throw an error only part of the
> time.

I think it's a bug in conch.

> The little program to reproduce the issue is found at
>
>    http://gist.github.com/321403
>
>    (raw version for download)
>    http://gist.github.com/raw/321403/82ab2111a2709c8fe50a77aabb08565749087408/gitconnbug.py
>
> and can be executed to start the sample server.  Run a command like
>
>    # The /abspath/to/git/repo should be readable by the server user
>    $ git clone ssh://user@localhost:2222/abspath/to/git/repo
>    (password "user")
>
> To test the server.  On my workstation, I am able to reproduce the
> error at least once every 5 tries.  It's definitely not consistent.
> The behavior I see is attached at the end of this email.  The client
> fails due to a premature inConnectionLost() call in the
> SSHSessionProcessProtocol that sends an EOF.
>
> As a workaround, when TraceProcessProtocol.inConnectionLost() is
> overriden to do nothing, the client error goes away.  This is somewhat
> foreign territory for me so I'm not sure whether it's a bug in git or
> whether it's a bug in the twisted ProcessProtocol implementation.  RFC
> 4254 isn't terribly helpful here:
>
>    5.3.  Closing a Channel
>
>       When a party will no longer send more data to a channel, it SHOULD
>       send SSH_MSG_CHANNEL_EOF.
>
> So on the surface the current behavior of sending an EOF appears fine,
> however, I can't really find any definitive cases of this type of
> problem popping up via, say, default OpenSSH/git combinations.
>
>
> Any advice?  Is the gitconnbug.py implementation flawed?  Should I
> open a ticket?  Any git experts know of a case where git-upload-pack
> might close it's stdout pipe?

I think what's actually happening here is that git-upload-pack is
closing its *stdin*.  Why conch reacts to that by shutting down the
channel, I don't really know -- it doesn't seem right to me.  Maybe
it's a simple logic error and it method should be
'outConnectionClosed' instead?

At any rate, I think this is a bug -- please file a ticket.  And
thanks for the complete example!

Cheers,
mwh




More information about the Twisted-Python mailing list