[Twisted-Python] (conch) credentials.signature always None?

[Saúl Ibarra Corretgé]

Hi all,

I'm experiencing something weird while writing a simple SSH server,
and I wonder if anyone did run into this before:

On every snippet I see around regarding public key authentication, the
signature is checked as follows:

#if not credentials.signature:
#return failure.Failure(ValidPublicKey())
#try:
#public_key = keys.Key.fromString(data=credentials.blob)
#except (keys.BadKeyError, keys.EncryptedKeyError):
#return failure.Failure(ConchError("Public key error"))

However, I'm always getting None there and thus the authentication
cannot proceed. I printed its value in the sshsimpleserver.py from the
examples directory and same seems to be happening, so I guess it's not
only my script :-S

Any clue?

Thanks in advance!

-- 
/Saúl
http://saghul.net | http://sipdoc.net

___
Twisted-Python mailing list
Twisted-Python@twistedmatrix.com
http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python

Re: [Twisted-Python] (conch) credentials.signature always None?

[Paul Swartz]

On Wed, Jan 19, 2011 at 6:55 PM, Saúl Ibarra Corretgé  wrote:
> Hi all,
>
> I'm experiencing something weird while writing a simple SSH server,
> and I wonder if anyone did run into this before:
>
> On every snippet I see around regarding public key authentication, the
> signature is checked as follows:
>
> #        if not credentials.signature:
> #            return failure.Failure(ValidPublicKey())
> #        try:
> #            public_key = keys.Key.fromString(data=credentials.blob)
> #        except (keys.BadKeyError, keys.EncryptedKeyError):
> #            return failure.Failure(ConchError("Public key error"))

If it's not continuing, that's a problem with the other side.  What
happens with the SSH protocol is:

C: sends a message asking 'if this public key okay?' without sending
any signed data
S: says either "no it's not valid for this account" or "yes it is
valid, please prove you have the private key"
C: if yes, sign some data and send the signature; otherwise try a
different key or different authentication mechanism

The 'if not credentials.signature: return
failure.Failure(ValidPublicKey())' code is how the server tells the
client it's a valid key, but needs to prove it also has the public
key.

-p
-- 
Paul Swartz
paulswartz at gmail dot com
http://paulswartz.net/
AIM: z3penguin

___
Twisted-Python mailing list
Twisted-Python@twistedmatrix.com
http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python

Re: [Twisted-Python] (conch) credentials.signature always None?

[Saúl Ibarra Corretgé]

Hi Paul,

Thanks for that quick response!

On Thu, Jan 20, 2011 at 1:06 AM, Paul Swartz  wrote:
> On Wed, Jan 19, 2011 at 6:55 PM, Saúl Ibarra Corretgé  
> wrote:
>> Hi all,
>>
>> I'm experiencing something weird while writing a simple SSH server,
>> and I wonder if anyone did run into this before:
>>
>> On every snippet I see around regarding public key authentication, the
>> signature is checked as follows:
>>
>> #        if not credentials.signature:
>> #            return failure.Failure(ValidPublicKey())
>> #        try:
>> #            public_key = keys.Key.fromString(data=credentials.blob)
>> #        except (keys.BadKeyError, keys.EncryptedKeyError):
>> #            return failure.Failure(ConchError("Public key error"))
>
> If it's not continuing, that's a problem with the other side.  What
> happens with the SSH protocol is:
>
> C: sends a message asking 'if this public key okay?' without sending
> any signed data
> S: says either "no it's not valid for this account" or "yes it is
> valid, please prove you have the private key"
> C: if yes, sign some data and send the signature; otherwise try a
> different key or different authentication mechanism
>
> The 'if not credentials.signature: return
> failure.Failure(ValidPublicKey())' code is how the server tells the
> client it's a valid key, but needs to prove it also has the public
> key.
>

My test was done wrong, my bad :-S I tested again and finally found
the issue: I'm searching for the user's key in a DB and errors are
handled in a errback. So ValidPublicKey was also handled there,
incorrectly.

I fixed it by doing the following:

def _got_keys_error(self, error, credentials):
if not error.check(ValidPublicKey):
return
failure.Failure(ConchError(error.getErrorMessage()))

So now it does work :-)

Thanks and regards,

-- 
/Saúl
http://saghul.net | http://sipdoc.net

___
Twisted-Python mailing list
Twisted-Python@twistedmatrix.com
http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python

Re: [Twisted-Python] (conch) credentials.signature always None?

[Glyph Lefkowitz]

On Jan 19, 2011, at 8:10 PM, Saúl Ibarra Corretgé wrote:

> I fixed it by doing the following:
> 
>def _got_keys_error(self, error, credentials):
>if not error.check(ValidPublicKey):
>return failure.Failure(ConchError(error.getErrorMessage()))

Are you sure that's what you want?  If you just say "I don't want to handle 
anything except FooError", i.e. the asynchronous equivalent to "except 
FooError", it's like this:

def myErrback(self, f):
f.trap(FooError)
# ... handle it ...


___
Twisted-Python mailing list
Twisted-Python@twistedmatrix.com
http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python

[Twisted-Python] Refactoring Documentation

[Tom Davis]

I've been using (and threatening to work on) Twisted for a few years now. It
seems like every time I get back into it, I need to dig up old code or
Google queries just to get started. Yesterday, Jean-Paul introduced me to
the trial-tutorial
branch
which
has shed some light on the basics of using trial and testing Twisted
client/server applications in general. Until he mentioned it in IRC, I was
stuck looking at the actual tests for protocols and deciding which parts of
that were generically useful to me. I agreed to finish up that documentation
so that it could finally (four years later) be added to trunk (and more
importantly, twistedmatrix.com). But after thinking about it, I believe the
problem runs much deeper than just the lack of a branch merge.

Reading code to find answers isn't rocket science; I've been programming
long enough to be comfortable doing it. But I probably have to resort to
reading Twisted's code about 8 billion percent more often than any other
codebase. And reading code is a hurdle. Reading through Twisted's
semi-random, 45-point FAQ is a hurdle—and recommending it as a starting
point is unhelpful at best. The core documentation isn't awesome either,
given that it has a tendency to be overly cryptic and link to API
documentation that is often incomplete or generally unhelpful.

As one very basic example, see:
http://twistedmatrix.com/documents/current/core/howto/servers.html. Let's
just review a few things wrong with this page:

   - It's tutorial page #1, but basically tells me I need to read
   howto/plugins.html first if I am writing an "application" (whatever that
   is), as opposed to a "TCP, SSL, and Unix socket server". And it's the wrong
   place for UDP.
   - It attempts to introduce Protocols and Factories—two of Twisted's most
   important concepts—and does neither particularly well. I know that Protocols
   (usually) inherit from t.i.p.Protocol and may be instantiated for a variety
   of reasons and aren't (usually) persistent. I also know that Factories
   instantiate Protocols and give a reference to themselves so protocols can
   "access and modify the persistent configuration". I am told I need to
   implement some interface (or something) to actually listen on a host/port. I
   think.
   - At one point "TCP4ServerEndpoint" is instantiated (but never imported);
   its explanation is left to a digression into the endpoints API, which has
   its own issues. Suffice it to say the document doesn't give me sufficient
   reason to actually use the endpoints API.
   - Later on, we just use reactor.listenTCP()—which our previous digression
   (if bothered to click through and read) claims is not preferable.

By the end of the *servers* tutorial (and after reading some linked
documentation), here's all I *really* know:

   1. Factories create protocols somehow
   2. Protocols have methods like connectionMade, connectionLost, and
   dataReceived to handle events
   3. There are other protocols with other methods. One that I know of,
   anyway.
   4. I may need to write a state machine (???)
   5. I should use an Endpoint or maybe a Service or reactor (but probably
   not!)
   6. I should also use Application for serious business

Moving forward, howto/clients.html duplicates a lot of these things and
fills in some gaps in knowledge while creating more holes. Meanwhile, I
still never wanted to create a QOTD or Echo server.

I think the point has been made. My *real* point, though, is that I love
Twisted. And I'm constantly wishing it was more accessible to newcomers.
Twisted is Python's oldest and most mature event-based networking engine and
despite its decade of existence it remains largely confusing and obscure to
the majority of Python programmers who come upon it. It contains concepts
and standards that are alien to the average Python programmer, but they make
a lot of sense and have a lot more consistency and predictability than the
documentation conveys.

I want to fix that, among other things. And as luck may have it, I like
writing documentation. And I know at least enough Twisted to get the
high-level stuff in order and improve the documentation to the point that
people will keep reading long enough to make sense of the "idea of Twisted"
and be able to implement some basic things and expand upon them later.

There are some things I *do* want to accomplish early on:

   - Make the docs accessible (a lot is hidden and hard to find)
   - Make them more concise and useful to somebody who doesn't want to know
   the 50 different ways to skin every cat (including the ones you should never
   use)
   - Make them introduce and explain Twisted in a way that somebody as dumb
   as me can understand it. This means talking about protocols, factories,
   deferreds, etc. in a way that doesn't require thousands of words of circular
   explanations, digressions, and duplications.
   - Document the different Twisted

Re: [Twisted-Python] (conch) credentials.signature always None?

[Saúl Ibarra Corretgé]

On Thu, Jan 20, 2011 at 6:18 AM, Glyph Lefkowitz
 wrote:
> On Jan 19, 2011, at 8:10 PM, Saúl Ibarra Corretgé wrote:
>
> I fixed it by doing the following:
>
>    def _got_keys_error(self, error, credentials):
>    if not error.check(ValidPublicKey):
>            return failure.Failure(ConchError(error.getErrorMessage()))
>
> Are you sure that's what you want?  If you just say "I don't want to handle
> anything except FooError", i.e. the asynchronous equivalent to "except
> FooError", it's like this:
> def myErrback(self, f):
>     f.trap(FooError)
>     # ... handle it ...
>

In this case I could get here (the errback) for several reasons,
depending on the DB backend, for example. I guess I could trap and all
the cases but ValidPrivateKey, but in this case I know for sure I want
ValidPrivateKey to be ignored, that's why I reversed the order. Or am
I missing something here?

Thanks!

-- 
/Saúl
http://saghul.net | http://sipdoc.net

___
Twisted-Python mailing list
Twisted-Python@twistedmatrix.com
http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python

Re: [Twisted-Python] (conch) credentials.signature always None?

[Glyph Lefkowitz]

On Jan 20, 2011, at 1:56 AM, Saúl Ibarra Corretgé wrote:

> In this case I could get here (the errback) for several reasons,
> depending on the DB backend, for example. I guess I could trap and all
> the cases but ValidPrivateKey, but in this case I know for sure I want
> ValidPrivateKey to be ignored, that's why I reversed the order. Or am
> I missing something here?

Nope, it sounds like you know what you're doing.  The example just looked 
slightly fishy (there wasn't quite enough there for me to really know what you 
were doing) and I wanted to make sure you were familiar with the usual idiom.  
Sorry for the false alarm!

___
Twisted-Python mailing list
Twisted-Python@twistedmatrix.com
http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python

Re: [Twisted-Python] Refactoring Documentation

[Kevin Horn]

On Thu, Jan 20, 2011 at 12:10 AM, Tom Davis  wrote:

> I've been using (and threatening to work on) Twisted for a few years now.
> It seems like every time I get back into it, I need to dig up old code or
> Google queries just to get started. Yesterday, Jean-Paul introduced me to
> the trial-tutorial 
> branch 
> which
> has shed some light on the basics of using trial and testing Twisted
> client/server applications in general. Until he mentioned it in IRC, I was
> stuck looking at the actual tests for protocols and deciding which parts of
> that were generically useful to me. I agreed to finish up that documentation
> so that it could finally (four years later) be added to trunk (and more
> importantly, twistedmatrix.com). But after thinking about it, I believe
> the problem runs much deeper than just the lack of a branch merge.
>
> Reading code to find answers isn't rocket science; I've been programming
> long enough to be comfortable doing it. But I probably have to resort to
> reading Twisted's code about 8 billion percent more often than any other
> codebase. And reading code is a hurdle. Reading through Twisted's
> semi-random, 45-point FAQ is a hurdle—and recommending it as a starting
> point is unhelpful at best. The core documentation isn't awesome either,
> given that it has a tendency to be overly cryptic and link to API
> documentation that is often incomplete or generally unhelpful.
>
> As one very basic example, see:
> http://twistedmatrix.com/documents/current/core/howto/servers.html. Let's
> just review a few things wrong with this page:
>
>- It's tutorial page #1, but basically tells me I need to read
>howto/plugins.html first if I am writing an "application" (whatever that
>is), as opposed to a "TCP, SSL, and Unix socket server". And it's the wrong
>place for UDP.
>- It attempts to introduce Protocols and Factories—two of Twisted's
>most important concepts—and does neither particularly well. I know that
>Protocols (usually) inherit from t.i.p.Protocol and may be instantiated for
>a variety of reasons and aren't (usually) persistent. I also know that
>Factories instantiate Protocols and give a reference to themselves so
>protocols can "access and modify the persistent configuration". I am told I
>need to implement some interface (or something) to actually listen on a
>host/port. I think.
>- At one point "TCP4ServerEndpoint" is instantiated (but never
>imported); its explanation is left to a digression into the endpoints API,
>which has its own issues. Suffice it to say the document doesn't give me
>sufficient reason to actually use the endpoints API.
>- Later on, we just use reactor.listenTCP()—which our previous
>digression (if bothered to click through and read) claims is not 
> preferable.
>
> By the end of the *servers* tutorial (and after reading some linked
> documentation), here's all I *really* know:
>
>1. Factories create protocols somehow
>2. Protocols have methods like connectionMade, connectionLost, and
>dataReceived to handle events
>3. There are other protocols with other methods. One that I know of,
>anyway.
>4. I may need to write a state machine (???)
>5. I should use an Endpoint or maybe a Service or reactor (but probably
>not!)
>6. I should also use Application for serious business
>
> Moving forward, howto/clients.html duplicates a lot of these things and
> fills in some gaps in knowledge while creating more holes. Meanwhile, I
> still never wanted to create a QOTD or Echo server.
>
> I think the point has been made. My *real* point, though, is that I love
> Twisted. And I'm constantly wishing it was more accessible to newcomers.
> Twisted is Python's oldest and most mature event-based networking engine and
> despite its decade of existence it remains largely confusing and obscure to
> the majority of Python programmers who come upon it. It contains concepts
> and standards that are alien to the average Python programmer, but they make
> a lot of sense and have a lot more consistency and predictability than the
> documentation conveys.
>
> I want to fix that, among other things. And as luck may have it, I like
> writing documentation. And I know at least enough Twisted to get the
> high-level stuff in order and improve the documentation to the point that
> people will keep reading long enough to make sense of the "idea of Twisted"
> and be able to implement some basic things and expand upon them later.
>
> There are some things I *do* want to accomplish early on:
>
>- Make the docs accessible (a lot is hidden and hard to find)
>- Make them more concise and useful to somebody who doesn't want to
>know the 50 different ways to skin every cat (including the ones you should
>never use)
>- Make them introduce and explain Twisted in a way that somebody as
>dumb as me can under

Re: [Twisted-Python] Refactoring Documentation

[Glyph Lefkowitz]

Let me begin by saying that I'm _very_ excited about this prospect and I'm 
looking forward to the output of this project.  So, some of what I'm about to 
say may sound like harsh criticism but please do not let it discourage you.  I 
agree with pretty much everything you're saying about problems with the current 
documentation.  They need to be fixed.  I'm offering criticism at this early 
stage in the hopes that it will be useful and feed into your project, not in 
the hopes that it will stop you.

On Jan 20, 2011, at 1:10 AM, Tom Davis wrote:

> I've been using (and threatening to work on) Twisted for a few years now. It 
> seems like every time I get back into it, I need to dig up old code or Google 
> queries just to get started. Yesterday, Jean-Paul introduced me to the 
> trial-tutorial branch which has shed some light on the basics of using trial 
> and testing Twisted client/server applications in general. Until he mentioned 
> it in IRC, I was stuck looking at the actual tests for protocols and deciding 
> which parts of that were generically useful to me. I agreed to finish up that 
> documentation so that it could finally (four years later) be added to trunk 
> (and more importantly, twistedmatrix.com). But after thinking about it, I 
> believe the problem runs much deeper than just the lack of a branch merge.

Yet, the problem _starts_ with a branch merge.

There are many outstanding documentation branches which are substantial 
improvements, which need to be edited and merged - the trial tutorial among 
them.  It would be great if your efforts could start with getting those landed, 
turning the crank on the process to get our users better documentation in the 
interim, as you survey the existing documentation.
> Factories create protocols somehow
> Protocols have methods like connectionMade, connectionLost, and dataReceived 
> to handle events
> There are other protocols with other methods. One that I know of, anyway.
> I may need to write a state machine (???)
> I should use an Endpoint or maybe a Service or reactor (but probably not!)
> I should also use Application for serious business
> Moving forward, howto/clients.html duplicates a lot of these things and fills 
> in some gaps in knowledge while creating more holes. Meanwhile, I still never 
> wanted to create a QOTD or Echo server.
> 
> I think the point has been made.

This kind of tear-down is pretty easy: I'd really like to hear your idea of its 
inverse, though.  What should a newcomer who reads this document know by the 
end of it?  A massive pile of improved documentation would of course be useful, 
but a good start would be a clear statement of requirements and audience.  (As 
well as an enumeration of different audiences that different documents might 
serve.)

> My real point, though, is that I love Twisted. And I'm constantly wishing it 
> was more accessible to newcomers. Twisted is Python's oldest and most mature 
> event-based networking engine

(minor nitpick: I really like "event-based" or "event-driven", as you've said 
here: why does  say "asynchronous"? I 
find that especially in documentation it's a lot easier to explain 
"event-driven", because you can enumerate what the events are, instead of 
explaining the etymology of "synchronicity"...)

> I want to fix that, among other things. And as luck may have it, I like 
> writing documentation. And I know at least enough Twisted to get the 
> high-level stuff in order and improve the documentation to the point that 
> people will keep reading long enough to make sense of the "idea of Twisted" 
> and be able to implement some basic things and expand upon them later.
> 
> There are some things I do want to accomplish early on:
> Make the docs accessible (a lot is hidden and hard to find)
> Make them more concise and useful to somebody who doesn't want to know the 50 
> different ways to skin every cat (including the ones you should never use)
> Make them introduce and explain Twisted in a way that somebody as dumb as me 
> can understand it. This means talking about protocols, factories, deferreds, 
> etc. in a way that doesn't require thousands of words of circular 
> explanations, digressions, and duplications.
> Document the different Twisted projects as what they are: really useful 
> libraries and/or clients/servers built on top of Twisted that just so happens 
> to also ship with the core. One of them is likely to do what the prospective 
> user wants, too.
These all sound like excellent goals.

> There are also some things I don't want to accomplish, at least initially:
> Explain asynchronous programming in depth
> Get into the level of detail that the Krondo series does (but I plan to 
> borrow from it!)
> There are things I'll need help with:
> The final word on what is/isn't to be used in what context; practical, 
> real-world explanations of why I would use A instead of B (not just "it's 
> more flexible").
You will prob