Norman Rasmussen writes:
- The tcpdumps look like the hash is being computed fine. (as my
- reading of JEP-0114 goes).
I guess it's time for me to wade through that JEP as
well..
- My guess would be that jabberd2's implementation is broken. Perhaps
- there's a newline being inserted somewhere during the hash
- calculation, or the jabberd2 alpha/64/endian build is broken).
I'd almost bet something with the non-32 bit integers is
involved. Just not sure if it's in Python or in jabberd2..
- I'm not sure why jcr is working, can you get a tcpdump of /that/
- connection attempt?
Sure.. http://www.cirr.com/~eric/muc-jcr-connect.txt
And for general amusement, here's a connection attempt
from pyicq, which fails (which was expected.)
http://www.cirr.com/~eric/pyicq-connect.txt
The shared secret used is the same as before.
(``Apot4AuTIA1iY95YsAkE'')
Thank you for all the assistance,
Eric
--
Eric Schnoebelen [EMAIL PROTECTED]
http://www.cirr.com
"A supercomputer is any computer which turns a CPU bound problem
into an I/O bound problem." -- Unknown
From [EMAIL PROTECTED] Thu Dec 29 10:05:59 2005
From: [EMAIL PROTECTED] (Norman Rasmussen)
Date: Thu Dec 29 10:06:05 2005
Subject: [py-transports] PyMSNt problems with shared secrets longer than
15 characters
In-Reply-To: <[EMAIL PROTECTED]>
References: <[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>
Message-ID: <[EMAIL PROTECTED]>
obviously whatever bug is causing jabberd2 to mangle the auth, is
_also_ affecting jcr's calculations - hence why jcr is working.
Could you post some of the auth's for pymsnt/pyicqt/jcr with shorted
passwords - i.e. they should all work. I'd like to double check that
my understanding of the JEP is right. FYI: Check out tcpflow if you
can :-)
I'd be tempted to say, rip out the sha1 hash calculations from
jabberd2/jcr and test them separately from the whole jabber
environment. i.e. with constant inputs, etc.
If you add some debugging output then you could compare between i32
and a64 easily. (If you don't have/can't find a i32 machine, I'm
happy to run the code)
On 12/29/05, Eric Schnoebelen <[EMAIL PROTECTED]> wrote:
>
> Norman Rasmussen writes:
> - The tcpdumps look like the hash is being computed fine. (as my
> - reading of JEP-0114 goes).
>
> I guess it's time for me to wade through that JEP as
> well..
>
> - My guess would be that jabberd2's implementation is broken. Perhaps
> - there's a newline being inserted somewhere during the hash
> - calculation, or the jabberd2 alpha/64/endian build is broken).
>
> I'd almost bet something with the non-32 bit integers is
> involved. Just not sure if it's in Python or in jabberd2..
>
> - I'm not sure why jcr is working, can you get a tcpdump of /that/
> - connection attempt?
>
> Sure.. http://www.cirr.com/~eric/muc-jcr-connect.txt
>
> And for general amusement, here's a connection attempt
> from pyicq, which fails (which was expected.)
>
> http://www.cirr.com/~eric/pyicq-connect.txt
>
> The shared secret used is the same as before.
> (``Apot4AuTIA1iY95YsAkE'')
>
> Thank you for all the assistance,
> Eric
>
> --
> Eric Schnoebelen [EMAIL PROTECTED]
> http://www.cirr.com
> "A supercomputer is any computer which turns a CPU bound problem
> into an I/O bound problem." -- Unknown
> _______________________________________________
> py-transports mailing list
> py-transports@blathersource.org
> http://www.modevia.com/cgi-bin/mailman/listinfo/py-transports
>
--
- Norman Rasmussen
- Email: [EMAIL PROTECTED]
- Home page: http://norman.rasmussen.co.za/
From [EMAIL PROTECTED] Thu Dec 29 22:08:50 2005
From: [EMAIL PROTECTED] (Eric Langheinrich)
Date: Thu Dec 29 22:08:57 2005
Subject: [py-transports] Yahoo Python Transport???
Message-ID: <[EMAIL PROTECTED]>
Is there a Python Yahoo transport?
