Bug#1001708: segfault when attempting SEPA transfer (works in debian 11, but broken in unstable)

2021-12-17 Thread Martin Preuss
Hi,

only tarballs of AqBanking6.4.0 are affected, previous and next versions are 
not.


Regards
Martin


Am 17.12.21 um 11:01 schrieb Micha Lenk:
> Control: fixed -1 libaqbanking/6.4.1-1
> 
> Am 16.12.21 um 22:40 schrieb Harald Welte:
>> On Thu, Dec 16, 2021 at 01:48:11PM +0100, Micha Lenk wrote:
>>> Would you mind to give these versions another try, once they become
>>> available?
>>
>> confirmed fixed in current packages on 'unstable', thanks.
> 
> Thanks for the confirmation.
> 
> For whether 'stable' is affected as well (thanks to the hint of the relevant 
> commit) I'll leave this bug open and have a look later.
> 
> Regards,
> Micha
> 


-- 
"Things are only impossible until they're not."



Bug#1001708: segfault when attempting SEPA transfer (works in debian 11, but broken in unstable)

2021-12-17 Thread Micha Lenk

Control: fixed -1 libaqbanking/6.4.1-1

Am 16.12.21 um 22:40 schrieb Harald Welte:

On Thu, Dec 16, 2021 at 01:48:11PM +0100, Micha Lenk wrote:

Would you mind to give these versions another try, once they become
available?


confirmed fixed in current packages on 'unstable', thanks.


Thanks for the confirmation.

For whether 'stable' is affected as well (thanks to the hint of the 
relevant commit) I'll leave this bug open and have a look later.


Regards,
Micha



Bug#1001708: segfault when attempting SEPA transfer (works in debian 11, but broken in unstable)

2021-12-16 Thread Harald Welte
Dear Micha,

On Thu, Dec 16, 2021 at 01:48:11PM +0100, Micha Lenk wrote:

> in the upstream bug tracker the author suggested this bug to be fixed
> already in versions AqBanking 6.4.1 and Gwenhywfar 5.8.0. 

I built from source and can confirm this is correct.

> I've just uploaded fixed packages to the Debian archive.

I will test them as soon as possible.

The next question is whether there is any need for back-porting the fix to
stable?

AFAICT the relevant fix is actually only one commit:

commit 78d01bb9e0028f79a5dab1e290fa14e7526e4757
Author: Martin Preuss 
Date:   Wed Dec 15 21:42:53 2021 +0100

typemaker2: Fixed a bug (not setting pointers to NULL after free).


-- 
- Harald Weltehttp://laforge.gnumonks.org/

"Privacy in residential applications is a desirable marketing option."
  (ETSI EN 300 175-7 Ch. A6)



Bug#1001708: segfault when attempting SEPA transfer (works in debian 11, but broken in unstable)

2021-12-16 Thread Harald Welte
On Thu, Dec 16, 2021 at 01:48:11PM +0100, Micha Lenk wrote:
> Would you mind to give these versions another try, once they become
> available?

confirmed fixed in current packages on 'unstable', thanks.

-- 
- Harald Weltehttp://laforge.gnumonks.org/

"Privacy in residential applications is a desirable marketing option."
  (ETSI EN 300 175-7 Ch. A6)



Bug#1001708: segfault when attempting SEPA transfer (works in debian 11, but broken in unstable)

2021-12-16 Thread Micha Lenk

Hi Harald,

in the upstream bug tracker the author suggested this bug to be fixed 
already in versions AqBanking 6.4.1 and Gwenhywfar 5.8.0. I've just 
uploaded fixed packages to the Debian archive.


Would you mind to give these versions another try, once they become 
available?


Kind regards,
Micha



Bug#1001708: segfault when attempting SEPA transfer (works in debian 11, but broken in unstable)

2021-12-16 Thread Micha Lenk

Control: forwarded -1 https://www.aquamaniac.de/rdm/issues/250

Hi Harald,

thanks for your detailed bug reports and your attempts to track down 
where the issue got introduced first. As always I appreciate the level 
of detail you put into your bug reports, this is awesome!


Am 14.12.21 um 19:27 schrieb Harald Welte:

Same also is the case with upstream 6.1.0.  Building 5.8.2 unfortuantely
fails as it expects gwenhywfar-config to be present, while the new
version switched to pkg-config.  Even after patching the autoconf, it's
appears to be impossibel to build an old aqbanking5 against modern
gwenhywfar, so I'm a bit lost.

Is there an easy way to install previous aqbanking packages in unstable
before upgrading to 6.4.x?


When trying to work with older versions of AqBanking you should be aware 
that AqBanking and Gwenhywfar are projects written by the same upstream 
author, with more or less coupled development cycles. This means if you 
go back with the one library, you most probably also need to go back 
with the other library so they fit together.


However, working with older releases of Gwenhywfar and AqBanking will 
also bring back bugs that have their root cause not within the 
Gwen/AqBanking code base, but in the server behavior the AqBanking 
applications are talking to (the PSD2 related changes come to my mind). 
This could prevent going back beyond a certain point in time.


As for the reported segmentation fault, I'll need a bit of time to take 
a look into them (due to real life constraints at the moment). However, 
I've forwarded the issue to the upstream author, who will hopefully take 
a look soon.


Best regards,
Micha



Bug#1001708: segfault when attempting SEPA transfer (works in debian 11, but broken in unstable)

2021-12-14 Thread Harald Welte
misc correction: It's probably only about 10 years that I'm using
aqbanking in this setup.  In any case, it has been extremely stable for
me during that time.

As for the actual bug: I built aqbanking 6.3.2 (from upstream git) on
Debian unstable and the same problem can be observed there.  I verified
that the libaqbanking.so from the custom build is used in the process,
so it's clearly not using the Debian-packaged library.

Same also is the case with upstream 6.1.0.  Building 5.8.2 unfortuantely
fails as it expects gwenhywfar-config to be present, while the new
version switched to pkg-config.  Even after patching the autoconf, it's
appears to be impossibel to build an old aqbanking5 against modern
gwenhywfar, so I'm a bit lost.

Is there an easy way to install previous aqbanking packages in unstable
before upgrading to 6.4.x?

-- 
- Harald Weltehttp://laforge.gnumonks.org/

"Privacy in residential applications is a desirable marketing option."
  (ETSI EN 300 175-7 Ch. A6)