Re: SSH Tunneling implementation

On Tue, Jul 10, 2012 at 1:31 PM, Magnus Hagander <magnus(at)hagander(dot)net>wrote:

> On Tue, Jul 10, 2012 at 2:30 PM, Ashesh Vashi <
> ashesh(dot)vashi(at)enterprisedb(dot)com> wrote:
>
>> On Tue, Jul 10, 2012 at 5:56 PM, Magnus Hagander <magnus(at)hagander(dot)net>wrote:
>>
>>> On Tue, Jul 10, 2012 at 2:19 PM, Akshay Joshi
>>> <akshay(dot)joshi(at)enterprisedb(dot)com> wrote:
>>> >
>>> >
>>> > On Tue, Jul 10, 2012 at 5:16 PM, Dave Page <dpage(at)pgadmin(dot)org> wrote:
>>> >>
>>> >>
>>> >>
>>> >> On Tue, Jul 10, 2012 at 12:35 PM, Ashesh Vashi
>>> >> <ashesh(dot)vashi(at)enterprisedb(dot)com> wrote:
>>> >>>>
>>> >>>>
>>> >>> Why are we talking about using the external application here?
>>> >>
>>> >>
>>> >> Because I suggested giving it some thought in case it turns out we
>>> have no
>>> >> other option.
>>> >>
>>> >>>
>>> >>> The only problem with the current implementation - is that it does
>>> use
>>> >>> new APIs for tunneling.
>>> >>> We can change the implementation based on the current supplied
>>> libssh2 on
>>> >>> most linux flavours.
>>> >>> i.e. libssh2 - 1.2.7 or later
>>> >>>
>>> >>> I have asked Akshay to check - if we can modify the current
>>> >>> implementation to use the older version of libssh2. (feasibility)
>>> >>
>>> >>
>>> >> I've already asked him to investigate whether there is another API
>>> that
>>> >> may be used that he may have missed. Only supporting old versions of
>>> libssh2
>>> >> is unacceptable though - we need to support current versions, and
>>> ideally
>>> >> older ones as well for compatibility with Ubuntu/Debian/RHEL etc.
>>> >
>>> >
>>> > I have investigated, there are two functions
>>> libssh2_session_handshake
>>> > and libssh2_exit() which is not available in the older versions.
>>> > libssh2_session_handshake() is replacement function to
>>> > libssh2_session_startup()(deprecated) which was added in the version
>>> 1.2.8
>>> > and
>>> > libssh2_exist() was added in the version 1.2.5. So to provide
>>> backward
>>> > compatibility we can perform the function check instead of configure
>>> > check and will add appropriate macros to build it properly.
>>> >
>>> > Thought??Comments?
>>>
>>> Uh, I'm not sure what you mean with "function check instead of
>>> configure check". You mean trying to load the function at runtime,
>>> with dlopen() and friends? I guess we could, but I don't think pgadmin
>>> has any functionality for that today, so it's going to bring in a fair
>>> amount of platform specific code, isn't it? But if it's not too
>>> complicated, it seems like a good choice.
>>>
>> He means to say - check function check at configuration.
>> i.e.
>> A lot of system does not have snprintf supported so a lot of packages
>> check existence of it at configuration and define HAVE_SNPRINTF macros.
>>
>
>
> Oh, that's what I would've called a configure check :) In that case, +1
> for that since it's clearly the simplest way of getting it done.
>
>
Yeah. Well, that should solve the version compatibility issue, but we still
want to find out if there's a different API to use to avoid the need for a
public key. Probably best to try to answer that first, in case it means
approaching things differently.

BTW; according to the libssh2 website I just read, it supports OpenSSL and
gcrypt, so I guess there won't be builds out there using libnss or gnutls.

--
Dave Page
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnake

EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise PostgreSQL Company