From Charles_Duffy at messageone.com  Mon May  5 10:25:20 2008
From: Charles_Duffy at messageone.com (Charles Duffy)
Date: Mon, 5 May 2008 12:25:20 -0500
Subject: [paramiko] OpenSSH sftp server returns EOF after directory listing,
	paramiko does not.
Message-ID: <44B5599C8B5B1347AFF903FDCEC0030706310D53@auscorpex-1.austin.messageone.com>

Per subject - if my interpretation of the behavior described below is
correct, lftp (even as current as 3.7.1) appears to be relying on this
behavior.

 

Running against my paramiko-based server, lftp hangs indefinitely trying
to run a directory listing:

 

---- path on wire is `/'

---> sending a packet, length=10, type=11(OPENDIR), id=4

<--- got a packet, length=12, type=102(HANDLE), id=4

---- got file handle 687831 (3)

---> sending a packet, length=12, type=12(READDIR), id=5

<--- got a packet, length=231, type=104(NAME), id=5

---- file name count=2

---> sending a packet, length=12, type=12(READDIR), id=6

---> sending a packet, length=12, type=12(READDIR), id=7

<--- got a packet, length=24, type=101(STATUS), id=6

<--- got a packet, length=24, type=101(STATUS), id=7 

  ^^ hangs here until interrupted

 

...whereas when running against an OpenSSH  server, behavior is quite
different:

 

---- path on wire is `//home/cduffy/tmp/a'

---> sending a packet, length=28, type=11(OPENDIR), id=4

<--- got a packet, length=13, type=102(HANDLE), id=4

---- got file handle 00000000 (4)

---> sending a packet, length=13, type=12(READDIR), id=5

<--- got a packet, length=501, type=104(NAME), id=5

---- file name count=5

---> sending a packet, length=13, type=12(READDIR), id=6

---> sending a packet, length=13, type=12(READDIR), id=7

<--- got a packet, length=28, type=101(STATUS), id=6

---- status code=1(EOF), message=End of file

---- eof

<--- got a packet, length=28, type=101(STATUS), id=7

---- status code=1(EOF), message=End of file

drwxr-xr-x    4 cduffy   cduffy       4096 May  4 17:48 .

drwxr-xr-x    4 cduffy   cduffy       4096 May  4 17:33 ..

-rw-r--r--    1 cduffy   cduffy          0 May  4 17:48 A

drwxr-xr-x    3 cduffy   cduffy       4096 May  4 17:33 b

drwxr-xr-x    3 cduffy   cduffy       4096 May  4 17:33 d

---> sending a packet, length=13, type=4(CLOSE), id=8

<--- got a packet, length=24, type=101(STATUS), id=8

---- status code=0(OK), message=Success

 

It appears that STATUS packets 6 and 7 from OpenSSH signal EOF, while
those from paramiko signal some other status (perhaps OK?) which lftp
doesn't see fit to comment on, even on a maximal debug level.

 

Is this difference in behavior intentional? Is it within the letter of
the sftp standard? (Where *is* the sftp standard? I've had a fair bit of
trouble googling it up).

 

Thanks!

 

-- 


Charles Duffy

Systems Engineering

charles_duffy at messageone.com

http://www.messageone.com <http://www.messageone.com/> 

Dell MessageOne
11044 Research Blvd
Building C, Fifth Floor
Austin, TX 78759

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.lag.net/pipermail/paramiko/attachments/20080505/39cf3299/attachment.html 

From smartpawn at gmail.com  Tue May  6 07:01:26 2008
From: smartpawn at gmail.com (Deepak Rokade)
Date: Tue, 6 May 2008 19:31:26 +0530
Subject: [paramiko] paramiko Digest, Vol 40, Issue 11
In-Reply-To: <mailman.3.1208631604.21691.paramiko@lag.net>
References: <mailman.3.1208631604.21691.paramiko@lag.net>
Message-ID: <48224a820805060701g4a82fac5sd81ddb1c3c33f737@mail.gmail.com>

Hi,
If we have got fix to deadlock in paramio issue ,
Are we planning any release with this fix ?
When can it be expected ?



------------------------------
>
> Message: 2
> Date: Fri, 18 Apr 2008 14:15:36 -0600
> From: Dwayne Litzenberger <dwayne at oscl.ca>
> Subject: [paramiko] [MERGE] Fix obscure deadlock that can occur during
>        re-keying
> To: paramiko at lag.net
> Message-ID: <200804181415.40332.dwayne at oscl.ca>
> Content-Type: text/plain; charset="iso-8859-1"
>
> Robey,
>
> I've attached a patch does the following:
>
> - Fix deadlock: Paramiko sometimes deadlocks if the user tries to send
> data
>  immediately after paramiko has initiated a key exchange (re-keying), but
>  before the remote MSG_KEXINIT has been received.  The deadlock occurs
> when
>  certain messages are received (e.g. MSG_CHANNEL_WINDOW_ADJUST) that were
>  in-transit when the initial MSG_KEXINIT was sent.
>
> - Add a test case for the deadlock
>
> - Fix __dump_packets support for SFTPServer and SFTPClient.  (Needed to
> make
> test.py work when Packetizer.__dump_packets = True.
>
> <shameless-plug>
> This patch took about 38 hours to produce, and was funded entirely by my
> employer, Open Systems Canada Limited.  They also paid for a lot of my
> work
> on the PRNG bugfixes (especially the as-yet unmerged rng*.py
> implementation).
> Basically, everything that came from my oscl.ca email address has been
> paid
> for by them.  It would be nice if they got some credit somewhere...
>  They're
> a small, FOSS-friendly IT services firm that could use the brand exposure.
> </shameless-plug>
>
> Cheers,
>  - Dwayne
>
> On April 15, 2008 04:58:05 pm Dwayne Litzenberger wrote:
> > On April 15, 2008 01:03:00 pm Dwayne Litzenberger wrote:
> > > In the main thread:
> > >
> > > Channel.send acquires Channel.lock, calls
> Channel._wait_for_send_window,
> > > then calls Transport._send_user_message with a MSG_CHANNEL_DATA
> message.
> > > Transport._send_user_message then waits for Transport.clear_to_send to
> be
> > > set, but it's not set for some reason.  Note that Channel.lock is
> still
> > > held by the main thread.
> > >
> > > Meanwhile, the Transport thread tries to process a MSG_WINDOW_ADJUST
> > > message. It calls Channel._window_adjust, but that can't proceed until
> > > Channel.lock is released.
> >
> > clear_to_send is unset (correctly) because we've just sent MSG_KEXINIT.
> > The problem seems to be that Channel.send() is holding Channel.lock,
> thus
> > preventing still-in-transit messages like MSG_WINDOW_ADJUST from being
> > processed by the Transport thread, even though we haven't received the
> > remote side's MSG_KEXINIT yet.
>
> --
> Dwayne Litzenberger, B.A.Sc.
> Information Technology Analyst
>
> Open Systems Canada Limited
> #210 - 2332 11th Ave
> Regina, SK S4P0K1
> Office: (306) 359-OSCL (6725)
> http://www.oscl.ca/
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: paramiko-deadlock-bugfix-and-testcase.bundle
> Type: text/x-diff
> Size: 16007 bytes
> Desc: not available
> Url :
> http://www.lag.net/pipermail/paramiko/attachments/20080418/005dc7f2/attachment-0001.diff
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: not available
> Type: application/pgp-signature
> Size: 189 bytes
> Desc: This is a digitally signed message part.
> Url :
> http://www.lag.net/pipermail/paramiko/attachments/20080418/005dc7f2/attachment-0001.pgp
>
> ------------------------------
>
> _______________________________________________
> paramiko mailing list
> paramiko at lag.net
> http://www.lag.net/cgi-bin/mailman/listinfo/paramiko
>
> End of paramiko Digest, Vol 40, Issue 11
> ****************************************
>



-- 
Thanx & Regards,
Deepak Rokade

Do what u Enjoy &
Enjoy what u Do...........
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.lag.net/pipermail/paramiko/attachments/20080506/00dd87e9/attachment.htm 

From Charles_Duffy at messageone.com  Tue May  6 15:59:21 2008
From: Charles_Duffy at messageone.com (Charles Duffy)
Date: Tue, 6 May 2008 17:59:21 -0500
Subject: [paramiko] OpenSSH sftp server returns EOF after directory
	listing, paramiko does not.
In-Reply-To: <44B5599C8B5B1347AFF903FDCEC0030706310D53@auscorpex-1.austin.messageone.com>
References: <44B5599C8B5B1347AFF903FDCEC0030706310D53@auscorpex-1.austin.messageone.com>
Message-ID: <44B5599C8B5B1347AFF903FDCEC003070631117C@auscorpex-1.austin.messageone.com>

My initial diagnosis of this issue was incorrect - paramiko is clearly
sending back EOF where it's supposed to.

 

I'm digging into lftp to try to track this down.

-- 


Charles Duffy

Systems Engineering

charles_duffy at messageone.com

http://www.messageone.com <http://www.messageone.com/> 

Dell MessageOne
11044 Research Blvd
Building C, Fifth Floor
Austin, TX 78759

 

From: paramiko-bounces at lag.net [mailto:paramiko-bounces at lag.net] On
Behalf Of Charles Duffy
Sent: Monday, May 05, 2008 12:25 PM
To: paramiko at lag.net
Subject: [paramiko] OpenSSH sftp server returns EOF after directory
listing,paramiko does not.

 

Per subject - if my interpretation of the behavior described below is
correct, lftp (even as current as 3.7.1) appears to be relying on this
behavior.

 

Running against my paramiko-based server, lftp hangs indefinitely trying
to run a directory listing:

 

---- path on wire is `/'

---> sending a packet, length=10, type=11(OPENDIR), id=4

<--- got a packet, length=12, type=102(HANDLE), id=4

---- got file handle 687831 (3)

---> sending a packet, length=12, type=12(READDIR), id=5

<--- got a packet, length=231, type=104(NAME), id=5

---- file name count=2

---> sending a packet, length=12, type=12(READDIR), id=6

---> sending a packet, length=12, type=12(READDIR), id=7

<--- got a packet, length=24, type=101(STATUS), id=6

<--- got a packet, length=24, type=101(STATUS), id=7 

  ^^ hangs here until interrupted

 

...whereas when running against an OpenSSH  server, behavior is quite
different:

 

---- path on wire is `//home/cduffy/tmp/a'

---> sending a packet, length=28, type=11(OPENDIR), id=4

<--- got a packet, length=13, type=102(HANDLE), id=4

---- got file handle 00000000 (4)

---> sending a packet, length=13, type=12(READDIR), id=5

<--- got a packet, length=501, type=104(NAME), id=5

---- file name count=5

---> sending a packet, length=13, type=12(READDIR), id=6

---> sending a packet, length=13, type=12(READDIR), id=7

<--- got a packet, length=28, type=101(STATUS), id=6

---- status code=1(EOF), message=End of file

---- eof

<--- got a packet, length=28, type=101(STATUS), id=7

---- status code=1(EOF), message=End of file

drwxr-xr-x    4 cduffy   cduffy       4096 May  4 17:48 .

drwxr-xr-x    4 cduffy   cduffy       4096 May  4 17:33 ..

-rw-r--r--    1 cduffy   cduffy          0 May  4 17:48 A

drwxr-xr-x    3 cduffy   cduffy       4096 May  4 17:33 b

drwxr-xr-x    3 cduffy   cduffy       4096 May  4 17:33 d

---> sending a packet, length=13, type=4(CLOSE), id=8

<--- got a packet, length=24, type=101(STATUS), id=8

---- status code=0(OK), message=Success

 

It appears that STATUS packets 6 and 7 from OpenSSH signal EOF, while
those from paramiko signal some other status (perhaps OK?) which lftp
doesn't see fit to comment on, even on a maximal debug level.

 

Is this difference in behavior intentional? Is it within the letter of
the sftp standard? (Where *is* the sftp standard? I've had a fair bit of
trouble googling it up).

 

Thanks!

 

-- 


Charles Duffy

Systems Engineering

charles_duffy at messageone.com

http://www.messageone.com <http://www.messageone.com/> 

Dell MessageOne
11044 Research Blvd
Building C, Fifth Floor
Austin, TX 78759

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.lag.net/pipermail/paramiko/attachments/20080506/b6253df2/attachment.htm 

From j_70 at comcast.net  Wed May  7 08:48:32 2008
From: j_70 at comcast.net (j_70 at comcast.net)
Date: Wed, 07 May 2008 15:48:32 +0000
Subject: [paramiko] Cannot find OS entropy source
Message-ID: <050720081548.23401.4821CF50000848D800005B692200734076CFC9A106@comcast.net>

   I am getting the following error trying to run Paramiko in python 2.5 on WinXP. 

 from osrandom import OSRandomPool
  File "C:\Python25\lib\paramiko\osrandom.py", line 129, in <module>
    raise ImportError("Cannot find OS entropy source")
ImportError: Cannot find OS entropy source

Am I missing a dependent library?


From Charles_Duffy at messageone.com  Wed May  7 09:43:56 2008
From: Charles_Duffy at messageone.com (Charles Duffy)
Date: Wed, 7 May 2008 11:43:56 -0500
Subject: [paramiko] [PATCH] missing language field on SSH_FXP_STATUS;
	fixes interop w/ lftp
In-Reply-To: <44B5599C8B5B1347AFF903FDCEC003070631117C@auscorpex-1.austin.messageone.com>
References: <44B5599C8B5B1347AFF903FDCEC0030706310D53@auscorpex-1.austin.messageone.com>
	<44B5599C8B5B1347AFF903FDCEC003070631117C@auscorpex-1.austin.messageone.com>
Message-ID: <44B5599C8B5B1347AFF903FDCEC003070631129B@auscorpex-1.austin.messageone.com>

It turns out that lftp expects SSH_FXP_STATUS packets to include a
language tag (which, looking at draft 3 [which I understand to be the
one paramiko's sftp support conforms to?], does appear to be mandatory),
and presently (prior to the 3.7.2 release), lftp doesn't play nice with
servers which fail to do so.

 

paramiko.sftp_server.SFTPServer._send_status sends a text field 'desc',
but no RFC-1766-compliant language field. The attached patch resolves
this, and fixes interoperability with lftp 3.7.1.

 

-- 


Charles Duffy

Systems Engineering

charles_duffy at messageone.com

http://www.messageone.com <http://www.messageone.com/> 

Dell MessageOne
11044 Research Blvd
Building C, Fifth Floor
Austin, TX 78759

 

From: paramiko-bounces at lag.net [mailto:paramiko-bounces at lag.net] On
Behalf Of Charles Duffy
Sent: Tuesday, May 06, 2008 5:59 PM
To: paramiko at lag.net
Subject: Re: [paramiko] OpenSSH sftp server returns EOF after
directorylisting, paramiko does not.

 

My initial diagnosis of this issue was incorrect - paramiko is clearly
sending back EOF where it's supposed to.

 

I'm digging into lftp to try to track this down.

-- 


Charles Duffy

Systems Engineering

charles_duffy at messageone.com

http://www.messageone.com <http://www.messageone.com/> 

Dell MessageOne
11044 Research Blvd
Building C, Fifth Floor
Austin, TX 78759

 

From: paramiko-bounces at lag.net [mailto:paramiko-bounces at lag.net] On
Behalf Of Charles Duffy
Sent: Monday, May 05, 2008 12:25 PM
To: paramiko at lag.net
Subject: [paramiko] OpenSSH sftp server returns EOF after directory
listing,paramiko does not.

 

Per subject - if my interpretation of the behavior described below is
correct, lftp (even as current as 3.7.1) appears to be relying on this
behavior.

 

Running against my paramiko-based server, lftp hangs indefinitely trying
to run a directory listing:

 

---- path on wire is `/'

---> sending a packet, length=10, type=11(OPENDIR), id=4

<--- got a packet, length=12, type=102(HANDLE), id=4

---- got file handle 687831 (3)

---> sending a packet, length=12, type=12(READDIR), id=5

<--- got a packet, length=231, type=104(NAME), id=5

---- file name count=2

---> sending a packet, length=12, type=12(READDIR), id=6

---> sending a packet, length=12, type=12(READDIR), id=7

<--- got a packet, length=24, type=101(STATUS), id=6

<--- got a packet, length=24, type=101(STATUS), id=7 

  ^^ hangs here until interrupted

 

...whereas when running against an OpenSSH  server, behavior is quite
different:

 

---- path on wire is `//home/cduffy/tmp/a'

---> sending a packet, length=28, type=11(OPENDIR), id=4

<--- got a packet, length=13, type=102(HANDLE), id=4

---- got file handle 00000000 (4)

---> sending a packet, length=13, type=12(READDIR), id=5

<--- got a packet, length=501, type=104(NAME), id=5

---- file name count=5

---> sending a packet, length=13, type=12(READDIR), id=6

---> sending a packet, length=13, type=12(READDIR), id=7

<--- got a packet, length=28, type=101(STATUS), id=6

---- status code=1(EOF), message=End of file

---- eof

<--- got a packet, length=28, type=101(STATUS), id=7

---- status code=1(EOF), message=End of file

drwxr-xr-x    4 cduffy   cduffy       4096 May  4 17:48 .

drwxr-xr-x    4 cduffy   cduffy       4096 May  4 17:33 ..

-rw-r--r--    1 cduffy   cduffy          0 May  4 17:48 A

drwxr-xr-x    3 cduffy   cduffy       4096 May  4 17:33 b

drwxr-xr-x    3 cduffy   cduffy       4096 May  4 17:33 d

---> sending a packet, length=13, type=4(CLOSE), id=8

<--- got a packet, length=24, type=101(STATUS), id=8

---- status code=0(OK), message=Success

 

It appears that STATUS packets 6 and 7 from OpenSSH signal EOF, while
those from paramiko signal some other status (perhaps OK?) which lftp
doesn't see fit to comment on, even on a maximal debug level.

 

Is this difference in behavior intentional? Is it within the letter of
the sftp standard? (Where *is* the sftp standard? I've had a fair bit of
trouble googling it up).

 

Thanks!

 

-- 


Charles Duffy

Systems Engineering

charles_duffy at messageone.com

http://www.messageone.com <http://www.messageone.com/> 

Dell MessageOne
11044 Research Blvd
Building C, Fifth Floor
Austin, TX 78759

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.lag.net/pipermail/paramiko/attachments/20080507/504fc439/attachment-0001.htm 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: paramiko_language_tag.diff
Type: application/octet-stream
Size: 1996 bytes
Desc: paramiko_language_tag.diff
Url : http://www.lag.net/pipermail/paramiko/attachments/20080507/504fc439/attachment-0001.obj 

From Charles_Duffy at messageone.com  Wed May  7 10:00:47 2008
From: Charles_Duffy at messageone.com (Charles Duffy)
Date: Wed, 7 May 2008 12:00:47 -0500
Subject: [paramiko] [PATCH] missing language field on SSH_FXP_STATUS;
	fixes interop w/ lftp
In-Reply-To: <44B5599C8B5B1347AFF903FDCEC003070631129B@auscorpex-1.austin.messageone.com>
References: <44B5599C8B5B1347AFF903FDCEC0030706310D53@auscorpex-1.austin.messageone.com><44B5599C8B5B1347AFF903FDCEC003070631117C@auscorpex-1.austin.messageone.com>
	<44B5599C8B5B1347AFF903FDCEC003070631129B@auscorpex-1.austin.messageone.com>
Message-ID: <44B5599C8B5B1347AFF903FDCEC00307063112AB@auscorpex-1.austin.messageone.com>

Filed a ticket (including a version of the patch with the current
language autodetection stripped out) at

https://bugs.launchpad.net/paramiko/+bug/227856

 

-- 


Charles Duffy

Systems Engineering

charles_duffy at messageone.com

http://www.messageone.com <http://www.messageone.com/> 

Dell MessageOne
11044 Research Blvd
Building C, Fifth Floor
Austin, TX 78759

 

From: paramiko-bounces at lag.net [mailto:paramiko-bounces at lag.net] On
Behalf Of Charles Duffy
Sent: Wednesday, May 07, 2008 11:44 AM
To: paramiko at lag.net
Subject: [paramiko] [PATCH] missing language field on
SSH_FXP_STATUS;fixes interop w/ lftp

 

It turns out that lftp expects SSH_FXP_STATUS packets to include a
language tag (which, looking at draft 3 [which I understand to be the
one paramiko's sftp support conforms to?], does appear to be mandatory),
and presently (prior to the 3.7.2 release), lftp doesn't play nice with
servers which fail to do so.

 

paramiko.sftp_server.SFTPServer._send_status sends a text field 'desc',
but no RFC-1766-compliant language field. The attached patch resolves
this, and fixes interoperability with lftp 3.7.1.

 

-- 


Charles Duffy

Systems Engineering

charles_duffy at messageone.com

http://www.messageone.com <http://www.messageone.com/> 

Dell MessageOne
11044 Research Blvd
Building C, Fifth Floor
Austin, TX 78759

 

From: paramiko-bounces at lag.net [mailto:paramiko-bounces at lag.net] On
Behalf Of Charles Duffy
Sent: Tuesday, May 06, 2008 5:59 PM
To: paramiko at lag.net
Subject: Re: [paramiko] OpenSSH sftp server returns EOF after
directorylisting, paramiko does not.

 

My initial diagnosis of this issue was incorrect - paramiko is clearly
sending back EOF where it's supposed to.

 

I'm digging into lftp to try to track this down.

-- 


Charles Duffy

Systems Engineering

charles_duffy at messageone.com

http://www.messageone.com <http://www.messageone.com/> 

Dell MessageOne
11044 Research Blvd
Building C, Fifth Floor
Austin, TX 78759

 

From: paramiko-bounces at lag.net [mailto:paramiko-bounces at lag.net] On
Behalf Of Charles Duffy
Sent: Monday, May 05, 2008 12:25 PM
To: paramiko at lag.net
Subject: [paramiko] OpenSSH sftp server returns EOF after directory
listing,paramiko does not.

 

Per subject - if my interpretation of the behavior described below is
correct, lftp (even as current as 3.7.1) appears to be relying on this
behavior.

 

Running against my paramiko-based server, lftp hangs indefinitely trying
to run a directory listing:

 

---- path on wire is `/'

---> sending a packet, length=10, type=11(OPENDIR), id=4

<--- got a packet, length=12, type=102(HANDLE), id=4

---- got file handle 687831 (3)

---> sending a packet, length=12, type=12(READDIR), id=5

<--- got a packet, length=231, type=104(NAME), id=5

---- file name count=2

---> sending a packet, length=12, type=12(READDIR), id=6

---> sending a packet, length=12, type=12(READDIR), id=7

<--- got a packet, length=24, type=101(STATUS), id=6

<--- got a packet, length=24, type=101(STATUS), id=7 

  ^^ hangs here until interrupted

 

...whereas when running against an OpenSSH  server, behavior is quite
different:

 

---- path on wire is `//home/cduffy/tmp/a'

---> sending a packet, length=28, type=11(OPENDIR), id=4

<--- got a packet, length=13, type=102(HANDLE), id=4

---- got file handle 00000000 (4)

---> sending a packet, length=13, type=12(READDIR), id=5

<--- got a packet, length=501, type=104(NAME), id=5

---- file name count=5

---> sending a packet, length=13, type=12(READDIR), id=6

---> sending a packet, length=13, type=12(READDIR), id=7

<--- got a packet, length=28, type=101(STATUS), id=6

---- status code=1(EOF), message=End of file

---- eof

<--- got a packet, length=28, type=101(STATUS), id=7

---- status code=1(EOF), message=End of file

drwxr-xr-x    4 cduffy   cduffy       4096 May  4 17:48 .

drwxr-xr-x    4 cduffy   cduffy       4096 May  4 17:33 ..

-rw-r--r--    1 cduffy   cduffy          0 May  4 17:48 A

drwxr-xr-x    3 cduffy   cduffy       4096 May  4 17:33 b

drwxr-xr-x    3 cduffy   cduffy       4096 May  4 17:33 d

---> sending a packet, length=13, type=4(CLOSE), id=8

<--- got a packet, length=24, type=101(STATUS), id=8

---- status code=0(OK), message=Success

 

It appears that STATUS packets 6 and 7 from OpenSSH signal EOF, while
those from paramiko signal some other status (perhaps OK?) which lftp
doesn't see fit to comment on, even on a maximal debug level.

 

Is this difference in behavior intentional? Is it within the letter of
the sftp standard? (Where *is* the sftp standard? I've had a fair bit of
trouble googling it up).

 

Thanks!

 

-- 


Charles Duffy

Systems Engineering

charles_duffy at messageone.com

http://www.messageone.com <http://www.messageone.com/> 

Dell MessageOne
11044 Research Blvd
Building C, Fifth Floor
Austin, TX 78759

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.lag.net/pipermail/paramiko/attachments/20080507/5029212e/attachment.htm 

From dlitz at dlitz.net  Thu May 15 20:43:40 2008
From: dlitz at dlitz.net (Dwayne C. Litzenberger)
Date: Thu, 15 May 2008 21:43:40 -0600
Subject: [paramiko] Cannot find OS entropy source
In-Reply-To: <050720081548.23401.4821CF50000848D800005B692200734076CFC9A106@comcast.net>
References: <050720081548.23401.4821CF50000848D800005B692200734076CFC9A106@comcast.net>
Message-ID: <20080516034340.GA29661@rivest.dlitz.net>

On Wed, May 07, 2008 at 03:48:32PM +0000, j_70 at comcast.net wrote:
>   I am getting the following error trying to run Paramiko in python 2.5 on WinXP. 
>
> from osrandom import OSRandomPool
>  File "C:\Python25\lib\paramiko\osrandom.py", line 129, in <module>
>    raise ImportError("Cannot find OS entropy source")
>ImportError: Cannot find OS entropy source
>
>Am I missing a dependent library?

What happens when you run the following Python program?

# --- snip ---
import os
print repr(os.urandom(8))
# --- snip ---

I did my testing on Python 2.5 on WinXP (Pro SP2) and it worked fine.

You might need pywin32 and pycrypto, if you don't have those already.

-- 
Dwayne C. Litzenberger <dlitz at dlitz.net>
  Key-signing key   - 19E1 1FE8 B3CF F273 ED17  4A24 928C EC13 39C2 5CF7
  Annual key (2008) - 4B2A FD82 FC7D 9E38 38D9  179F 1C11 B877 E780 4B45