On Fri, Jul 13, 2012 at 10:24 AM, Ashesh Vashi < ashesh.va...@enterprisedb.com> wrote:
> On Fri, Jul 13, 2012 at 2:45 PM, Magnus Hagander <mag...@hagander.net>wrote: > >> On Fri, Jul 13, 2012 at 10:32 AM, Dave Page <dp...@pgadmin.org> wrote: >> > On Fri, Jul 13, 2012 at 7:57 AM, Akshay Joshi >> > <akshay.jo...@enterprisedb.com> wrote: >> >> >> >> >> >> On Thu, Jul 12, 2012 at 5:44 PM, Magnus Hagander <mag...@hagander.net> >> >> wrote: >> >>> >> >>> On Thu, Jul 12, 2012 at 2:06 PM, Akshay Joshi >> >>> <akshay.jo...@enterprisedb.com> wrote: >> >>> > >> >>> > >> >>> > On Thu, Jul 12, 2012 at 5:21 PM, Dave Page <dp...@pgadmin.org> >> wrote: >> >>> >> >> >>> >> On Thu, Jul 12, 2012 at 12:04 PM, Akshay Joshi >> >>> >> <akshay.jo...@enterprisedb.com> wrote: >> >>> >> > Hi All >> >>> >> > >> >>> >> > I have tried a lot to figure out libssh2 is compiled with which >> >>> >> > crypto >> >>> >> > library, but unable to find it. Can someone guide/help me or do >> we >> >>> >> > continue >> >>> >> > with the public key option on UI? >> >>> >> >> >>> >> The libssh2 guys couldn't tell you how? >> >>> > >> >>> > >> >>> > I'll post this on mailing list, but I have found one solution >> to the >> >>> > problem is checking the function "libssh2_md5" using AC_CHECK_LIB as >> >>> > below >> >>> > AC_CHECK_LIB(ssh2, libssh2_md5, [IS_LIBSSH2_OPENSSL_CRYPTO=yes], >> >>> > [IS_LIBSSH2_OPENSSL_CRYPTO=no]) >> >>> > >> >>> > I have analyze libssh2 source code and found "libssh2_md5" is >> >>> > implemented >> >>> > only for openssl version not for the gcrypt. I have tested it with >> both >> >>> > the version of libssh2.so. >> >>> > >> >>> > Thoughts? Comments? >> >>> >> >>> Is there a way to test the actual function that we want to call >> >>> instead? Will it fail right away, or does it actually require there to >> >>> be a server somewhere that we can connect to? (If it requires a server >> >>> we can't use that one in configure, but if it will fail right away, >> >>> that seems like a better way to test it. >> >> >> >> >> >> To check the actual function we requires a valid server. Yesterday >> I have >> >> posted the problem to the libssh2 mailing list, but still didn't get >> >> response.Meanwhile >> >> I have fixed the review comments given by Dave. Attached is the >> complete >> >> patch with >> >> AC_CHECK_LIB(ssh2, libssh2_md5 [IS_LIBSSH2_OPENSSL_CRYPTO=yes], >> >> [IS_LIBSSH2_OPENSSL_CRYPTO=no]) and it works with both version of >> >> libssh2. >> >> >> >> Can we include libssh2 source code with pgAdmin3 to solve the >> problem? >> >> Thoughts??Comments? >> > >> > I discussed that with Ashesh on Skype yesterday - I thought he was >> > going to post to the list. Magnus suggested that option, and I'm >> > beginning to think it's the way forward. The licence is compatible >> > from what I can see, so that shouldn't be a problem. Then, we'd just >> > modify the configure script to add a dependency on OpenSSL instead. >> >> Agreed. It seems libssh2 is just a little bit "too new" (IIRC it's >> been around for longer, but caught some "revival" not too long ago) - >> meaning that enterprise platforms like ubuntu LTS and RHEL are stuck >> on versions that are too old. >> >> So I think including it would be a good idea - at least for a couple >> of yeas until reality might change underneath us and make that >> unnecessary. >> >> One thing we should definitely have is a policy (and maybe scripts?) >> to make sure we keep it *updated*. It will require things like a >> security release of pgadmin whenever there is one of libssh2, and we >> need a good way to keep up with the proper minor version.. >> >> >> > If we do that though, we'd need to make it work if OpenSSL isn't >> > available on the build platform. I'd suggest that if configure isn't >> > given a valid OpenSSL installation (or can't find one), then we just >> > disable all the tunnelling options - just surround the appropriate >> > code in #ifdef OPENSSL or something and hide the tab on dlgServer. >> >> Hmm. But couldn't we still support tunneling with passwords, just not >> publickey? If so, I'd much rather see just that option grayed out >> (maybe have a text that says why, if there's room) than to remove the >> complete functionality. I know lots of people who use ssh with >> passwords only (e.g. LDAP integrations etc), that could benefit from >> this even if it doesn't come with key support. >> > I would prefer to have that feature which supplies of private and public > keys both or with password. > But - as libssh2 requires either openssl or libgcrypt. > If none found on the system, we can disable this feature. > Good point - we could have configure look for OpenSSL, if that's not found, look for gcrypt (and require the user to provide a public key to use a tunnel), or finally if neither are found, disable the tunnelling feature altogether. -- Dave Page Blog: http://pgsnake.blogspot.com Twitter: @pgsnake EnterpriseDB UK: http://www.enterprisedb.com The Enterprise PostgreSQL Company
