On Tue, Jul 10, 2012 at 1:31 PM, Magnus Hagander <mag...@hagander.net>wrote:
> On Tue, Jul 10, 2012 at 2:30 PM, Ashesh Vashi < > ashesh.va...@enterprisedb.com> wrote: > >> On Tue, Jul 10, 2012 at 5:56 PM, Magnus Hagander <mag...@hagander.net>wrote: >> >>> On Tue, Jul 10, 2012 at 2:19 PM, Akshay Joshi >>> <akshay.jo...@enterprisedb.com> wrote: >>> > >>> > >>> > On Tue, Jul 10, 2012 at 5:16 PM, Dave Page <dp...@pgadmin.org> wrote: >>> >> >>> >> >>> >> >>> >> On Tue, Jul 10, 2012 at 12:35 PM, Ashesh Vashi >>> >> <ashesh.va...@enterprisedb.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
