>> --- include/libssh2.h4 Nov 2006 19:30:31 - 1.60
>> +++ include/libssh2.h23 Nov 2006 17:06:42 -
>> @@ -172,8 +172,8 @@ typedef struct _LIBSSH2_POLLFD {
>> LIBSSH2_LISTENER *listener; /* Read polls only -- are inbound
>> connections waiting to be accepte
> In libcurl we use the libssh2_userauth_keyboard_interactive_ex() function to
> provide a password as if it was coming from the keyboard.
>
> I'm not an expert on this, but it seems we have to assign two struct members
> in one of the structs passed to the callback.
>
> The problem here is tha
[EMAIL PROTECTED] wrote:
> On Fri, 24 Nov 2006, Sara Golemon wrote:
>
>>> So, here's another suggest API break: I want to add a pointer to the
>>> proto for this function. A user pointer and I want that pointer
>>> passed on to the callback function in
> I've recently pushed several patches dangling in our local repository
> for a year. Please check don't they break something for you (we use
> them on Linux, FreeBSD and MacOSX without problems, but anyway...)
>
Thanks Mikhail, Good to hear from you again!
-Sara
[EMAIL PROTECTED] wrote:
>> I played with it a bit, and I could get something similar to the existing
>> format using these options:
>
> No comments at all? I'm about to start poking around for real in the code,
> and
> I simply cannot work with it as it currently looks.
>
Sorry, I missed this
[EMAIL PROTECTED] wrote:
> Daniel Stenberg <[EMAIL PROTECTED]> writes:
>
>> On Thu, 16 Nov 2006, Simon Josefsson wrote:
>>
>>> This removes the LIBSSH2_CRYPT_METHOD_FLAG_EVP flag (and the entire flag
>>> variable, although that part is not essential) and the flag's semantic.
>>>
>>> This moves so
> I want to modify libssh2 to always build with debug output ability when it is
> built with ./configure --enable-debug, and just provide a function to switch
> on/off the different outputs that currently are controlled with #ifdefs.
>
> I think it is very uncomfortable to have to reconf and reb
[EMAIL PROTECTED] wrote:
> I'm going to add '--copy' option to the 'automake --add-missing'
> clause in buildconf to make creating Debian packages a bit easier. Any
> objections?
>
Go for it! Anything to make things easier on those Debian folk! :)
-Sara
--
> However, the same file unconditionally uses SHA-1 in different places,
> so these #ifdef's doesn't work.
>
> All the ssh kex protocols that libssh2 supports require SHA-1, so it
> does not seem very useful to build libssh2 if there is no support for
> SHA-1 in OpenSSL. However, I may be missing
> I have installed this, at least it will make the autobuilder page more
> useful, right now it just says "Failure" because there are no self
> tests at all... see http://autobuild.josefsson.org/libssh2/
>
I should mention that I received an offer about a year ago from the
folks at VanDyke softwa
> Btw, is it ok to install my libgcrypt patches? If you'd like more
> time to review them, how about if I install it on a branch? That
> creates more work eventually, when the branch has to be merged with
> HEAD, but it will makes things easier for me and Daniel to test things
> with curl.
>
Kno
[EMAIL PROTECTED] wrote:
>>> The problem is that if I try to use libssh2_file_read_publickey
>>> -function with a publickey converted to SECSH format it
>>> failes "Invalid key data, not base64 encoded". As a result I can
>>> use only OpenSSH formatted keys and that is unacceptable from the
>>>
> I have no idea how to test the server mode of libssh2 though. Is that
> even supported? I see there are some RSA signing stuff going on, and
> I'd assume that is for the server side, but right now I'm to deep into
> details to remember how things worked on a high level.
>
There isn't one.
> First, I'm wondering if there's any further documentation or examples of
> how to go about using libssh2 in a serious program, particularly for
> terminal emulation support. The ssh2_sample.c kind of skimps out on
> that area, instead just saying that "this is where stuff happens". The
> AP
[EMAIL PROTECTED] wrote:
>>> Sorry for being lazy, but could you point me towards the
>>> document that defines the SECSH key formats?
>
> No problem, http://www.ietf.org/rfc/rfc4716.txt
>
This described public key formarts. Simon is working on reading private
keys. The SECSH public key forma
> I thought this was only about the disk-format, does it affect the wire
> format also? I'd assume that the protocol clearly specified the
> format of public keys on the wire.
>
The format of the blob which is sent over the wire is fixed and well
defined. It's basicly the base64 decode version
>> At this point, I think it would be useful for others to review the code and
>> comment on it. I'm sure there are mistakes, but I'm to deep into the code
>> to see them now.
>
> Nice work Simon!
>
Agreed! Excellent work! This doubles the options and opens the door for
inclusion in distrib
Thanks Chris!
I've added NewI\O to the "Projects using libssh2" section (Sorry the
page is protected, but it was getting too much attention from spammers).
Did you want it to say "by Chris Nystrom" or "by the NewI\O team" or
just as it is now?
-Sara
[EMAIL PROTECTED] wrote:
> Here is the anno
> I need a clarification here from you all regarding the functionality of
> HostBasedAuthentication.
>
> 1) If the remote SFTP server admin wants to allow only Host based
> authentication, then the remote sshd_config should have
> 'HostBasedAuthentication' set to yes, and the rest set to no, li
[EMAIL PROTECTED] wrote:
> The function libssh2_userauth_publickey_fromfile(), as used in the example
> scp.c and sftp.c programs, takes arguments for both the public and private
> keys of the user. However, the -i option in OpenSSH's scp and ssh takes
> only the private key to perform the same op
> I would like to propose some code style guidelines:
> - replace all tabs with 4 spaces, and use from now on spaces only.
> - either allways place the opening brace in a separate line, or allways
> append it, but dont mix both variants;
> dont know what's best - I personally like to have it app
> Eberhard Mattes has filed a bug report about
> the libssh2 use of 0xFF instead of 1 for a TRUE
> boolean value. He is correct about the RFC,
> http://www.faqs.org/rfcs/rfc4251.html , section 5.
> It does look like we are in the wrong, and have
> been since the beginning. My question is why mi
22 matches
Mail list logo
