Looking for a new (or co-) maintainer for Net::SSH::Perl and Net::SFTP
I took these modules over from the previous owner in order to fix some annoying circular references that cause memory and file descriptor leaks. Unfortunately, the modules came with a minimal test suite, and I haven't had the tuits to write one. Since I'm not an expert on the protocols being implemented, this makes me very leary of actually changing these modules, so the patches bug reports pile up. Lots of people appear to use them, so anyone who improves these modules will be much loved, no doubt ;) I'm happy to help some as co-maintainer, but I think they really need a motivated developer to work on them. I've posted similar pleas elsewhere in the past (the users list for the modules, my use perl journal, etc) but not gotten any answer. Anyone out there? -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
Re: Looking for a new (or co-) maintainer for Net::SSH::Perl and Net::SFTP
On Sat, 3 Jul 2004, Lincoln A. Baxter wrote: I am a user of these modules. And I am glad they exist. But I do not have a lot of time to do deep development on them, and I am not sure I know the internals of SSH protocols well enough to maintain them, especially since these are a reimplementation of ssh in perl (and require a ton of prerequisite modules). The really big thing that needs to be done is writing a real comprehensive test suite. If that existed, I'd be much more able (and willing) to try to fix bugs. But as it is, I'm afraid to mess with anything. There's a ton of code, and only the smallest portion of it is touched by the tests (there's no actual live tests against a server). If I were starting from scratch, I think I think about opening up OpenSSH to expose an API, and then build a perl wrapper for that API. Then all one would have to do, is build OpenSSH(lib), and most of the maintenance would come along for free. This assumes (of course) that the OpenSSH folks would accept patches to create a library. That's a nice idea, but definitely way more work than writing the above-mentioned test suite. I would think that the first thing that should be done, is to put the code up in subversion on perl.org, and invite patches. Tim Bunce put It's on SourceForge right now. I'd certainly be happy to move it to Subversion. one, have contributed to the DBD-Oracle code via subversion. (You can control who gets commit rights to those you trust, but this makes it easier for anyone to send patches, and easier for you to apply them, since they can always be made against a current code base (via a guest checkout). I'm quite familiar with Subversion, and definitely prefer it to CVS. I would also think about creating a bugzilla database, and maybe a users email list. (a la the XML::Xerces bugzilla and email list). This seems to be a model that works. We already have rt.cpan.org. I much prefer RT to bugzilla. There are plenty of tickets for these modules in RT already ;) -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
Re: Looking for a new (or co-) maintainer for Net::SSH::Perl and Net::SFTP
On Sat, 3 Jul 2004, Eric Wilhelm wrote: From what I can see, these modules are just making system calls to ssh or scp. You're not looking at the right modules, methinks. -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
Re: Looking for a new (or co-) maintainer for Net::SSH::Perl and Net::SFTP
# The following was supposedly scribed by # Dave Rolsky # on Saturday 03 July 2004 11:59 am: From what I can see, these modules are just making system calls to ssh or scp. You're not looking at the right modules, methinks. do'h! In that case, I'll go with Lincoln Baxter on the binding to openSSH thing. What I was originally going to suggest (before I looked up the wrong modules) is that you use Inline::C and essentially just replicate the 500-line main() function from ssh.c Of course, that won't get you a pure-perl implementation, so crippled systems without a compiler will have to make their usual sad face :( Testing-wise, you'll be in a bad boat on crippled systems as well. You may have to ask the user what ssh server to connect to and get a username/password in order to perform tests. --Eric -- Time flies like an arrow, but fruit flies like a banana. --Unknown
Re: Looking for a new (or co-) maintainer for Net::SSH::Perl and Net::SFTP
On Sat, 2004-07-03 at 13:42, Lincoln A. Baxter wrote: On Sat, 2004-07-03 at 12:51, Dave Rolsky wrote: Here, perhaps, is the start of a list: scp tiny file to server and back and diff. scp large file to server and back and diff. (same as above with sftp). scp a file to server, ssh to server and cat the file just copied across, write the output to a file and diff with original. I would add that one would want to repeat the above for for each supported encryption library... Blowfish, DES, etc... Hence the need for a test library, to eliminate redundant code. Of course, one would probably need to understand what the server supports here. I suspect we would have to discover that... H... but how? Maybe I do not understand this well enough yet. lincoln
Re: Looking for a new (or co-) maintainer for Net::SSH::Perl and Net::SFTP
On Sat, 3 Jul 2004, Eric Wilhelm wrote: In that case, I'll go with Lincoln Baxter on the binding to openSSH thing. What I was originally going to suggest (before I looked up the wrong modules) is that you use Inline::C and essentially just replicate the 500-line main() function from ssh.c Feel free to write this :) Again, this would be _more_ work than fixing up the current pure Perl version, which I don't have enough time to do, so suggestions that involve more work aren't going to be taken up by me. Testing-wise, you'll be in a bad boat on crippled systems as well. You may have to ask the user what ssh server to connect to and get a username/password in order to perform tests. Well, I think we'd need to do something more complex. Besides just needing a server username/pw, we need to know that certain things are available in the remote account. Another possibility is to write a dummy server that we test with that gives known responses to various inputs. This would be good enough for testing the client side bits. The distro also includes a psshd program we could use once we'd tested enough to be confident it'd work. I have lots of ideas, but not enough time! -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
Re: Looking for a new (or co-) maintainer for Net::SSH::Perl and Net::SFTP
On Sat, 3 Jul 2004, Lincoln A. Baxter wrote: On Sat, 2004-07-03 at 13:42, Lincoln A. Baxter wrote: On Sat, 2004-07-03 at 12:51, Dave Rolsky wrote: Here, perhaps, is the start of a list: scp tiny file to server and back and diff. scp large file to server and back and diff. (same as above with sftp). scp a file to server, ssh to server and cat the file just copied across, write the output to a file and diff with original. I wrote that? When? I would add that one would want to repeat the above for for each supported encryption library... Blowfish, DES, etc... Hence the need for a test library, to eliminate redundant code. Of course, one would probably need to understand what the server supports here. I suspect we would have to discover that... H... but how? Maybe I do not understand this well enough yet. As I mentioned in another message, there is a psshd program in the current distro that might be usable. I think for testing each type of crypto, we just try to connect to the server the user gives us. If it works, we run the tests, otherwise we skip them. No big deal. The developers can always make sure that they have all of them working. -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
Re: Looking for a new (or co-) maintainer for Net::SSH::Perl and Net::SFTP
On Sat, 3 Jul 2004, Ken Williams wrote: Ok, I could probably spend a little back ground time doing this. Lets make a list of tests that need to be created, and prioritize them. Sounds like a lot of work. Maybe as a first step, just use Devel::Cover to find out what parts of the code aren't being exercised, and exercise them better. That'd be about 90% of it. Basically anything that opens a socket and talks to something isn't being tested, and that's the vast bulk of the code. -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
