Thomas Viehmann <[EMAIL PROTECTED]> writes:
> Thomas Bushnell BSG wrote:
>> gnucash upstream doesn't care about ssl. We just want to link gnucash
>> against libaqbanking. The ssl parts are a loadable module (according to
>> upstream gnucash), and so it should be possible to provide an aqbanking
>> package
>> which doesn't depend on ssl at all.
> Well, IIRC libaqbanking itself doesn't use libssl, its dependency
> libgwenhywfar does. Now, crypto may be pluggable in gwenhywfar also, but
> what does that gain us?
Actually, aqbanking *does* use SSL:
$ ldd /usr/lib/libaqbanking.so
libgwenhywfar.so.38 => /usr/lib/libgwenhywfar.so.38 (0x6fe64000)
libc.so.6 => /lib/tls/libc.so.6 (0x6fcef000)
libssl.so.0.9.8 => /usr/lib/libssl.so.0.9.8 (0x6fc8c000)
libcrypto.so.0.9.8 => /usr/lib/libcrypto.so.0.9.8 (0x6fb0e000)
libdl.so.2 => /lib/tls/libdl.so.2 (0x6faea000)
/lib/ld.so.1 (0x08000000)
libz.so.1 => /usr/lib/libz.so.1 (0x6fab5000)
> While it could likely be done it would be very hackish and unusuable at
> least for the online banking (in particular HBCI) crowd.
> Of course, we could play circumvention games (link against one, use the
> other version of aqbanking), but is it really worth it?
> I'm not sure that would eliminate the legal concerns preventing a
> straightforward inclusion, either.
Circumvention games don't change reality at all.
I hear you saying that HBCI *requires* SSL to be useful; is that
because SSL is the normal way people authenticate to their bank?
What about (God forbid) *not using gwenhywfar at all*?
Perhaps aqbanking could just stick to well-supported interfaces?
Or, perhaps, gwenhywfar, which claims to be a *portability* library
after all, could offer this handy portability feature?
Thomas
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
