HBCI data structures and Gnucash

[Christian Stimming]

Darius Powell wrote:

> Benoit Grégoire <bock@step.polymtl.ca> writes:
>>>I'm currently working on a script to automatically download
>>>transactions.  Currently it generates qif files for import.
>>>
>>I am also currently working at this stage.  I have working ofx support for 
>>pretty much the whole specification for transaction download.  I can 
>>trivially export qif files, but i don't want to use such a mediocre transport 
>>format, after working so herd to support the whole spec.  
> 
> It would seem to make sense if there was a single way to get
> transactions into Gnucash (or more generally speaking to perform online
> banking actions) that we could both use.


That sounds good for OFX and QIF import. However, I'd like to point out 
again that HBCI support is different from this. HBCI is a standarized 
protocol, not a file format. HBCI acts as a authentication/encryption 
protocol on top of TCP *and* it standarizes the data format of actions 
that the bank should perform (wire transfer etc.) and of statements the 
bank returns.

Therefore I'm going to write a seperate loadable gnc-module for hbci 
support (which all people outside Germany can safely ignore). I.e. I 
would rather not put too much effort into code sharing between HBCI 
support and QIF import/export but first code the HBCI stuff on my own. 
Nevertheless there is some code that both of us will similarly need -- 
namely,  the transaction duplicate detection when importing/retrieving 
statements of the bank. I guess we should move those functions to some 
generic library and use them from there. But for HCBI, this won't be 
needed before July/August.


>>>It would be good if transactions were downloaded in the background at
>>>scheduled times (even if Gnucash is not running).  
>>>
>>I am not all sure this is a good idea.  There would be pretty steep security 
>>issues.  To download in the background at regular intervals, gnucash would 
>>have to keep the passwords necessary for access, 24h a day.  If we want to 
>>run even when gnucash is not, the passwords will have to be stored on disk!  
> 
> Yes, there are certainly some serious security concerns here.

> 
> As for automatic downloads the password needs to be stored somehow and
> should probably be encrypted.

Any HBCI support will definitely *not* store the password/passphrase 
anywhere on disk. Also, I don't quite see the point of transaction 
downloading in the background -- either I'm running my application and 
want to download the transactions, or I'm not running my application and 
don't care about the transactions. But anyway, for HBCI support password 
storing on disk won't happen. So your discussion doesn't apply to HBCI.

That said, I recall several discussions on this list about storing data 
in an encrypted way, the last having happened some months ago. We 
*always* came to the conclusion that this issue *cannot* be properly 
addressed by the application. If a user is seriously concerned about 
protecting her data against other people (with potentially physical 
access to the machine), an encrypted filesystem was about the only sound 
solution that we could come up with, and this is definitely beyond the 
scope of our application. I mean, you could start this discussion all 
over again, but what I took from those discussion was that I should 
basically forget about saving any encrypted data. So again, the HBCI 
support code will never store the passphrase anywhere in a file.

Christian