"correcting" transactions

[Maf. King]

On Fri 21 February 14 01:47:38 John Sowden wrote:
> On 02/21/2014 12:26 AM, David wrote:

> Re: the question of how to keep the program secure, I'll give it a try.
> 
> Prior to exit of the data entry in the program, a CRC of the datafile is
> created.
> Upon entry, the CRC is checked.  If it fails, a warning is presented to
> the user.
> No edits or deletions to the transaction database is allowed. Period.
> No changes to the account balances are allowed except via valid
> transactions. Period.
> 
> In other words, alterations to the transactions database, from which all
> reports are created can only be created via valid transactions.
> 
 
Hi John.
But.... gnucash is open source.  there is nothing to stop the bad guys taking 
a copy of the source code, modifying it to not check (or always accept) the 
CRC on load, then calculating a new CRC on exit which would be valid for 
"proper" gnucash, 

Then bad guy takes the data file, massages some figures (in a text editor if 
need be, or with enough motivation, bit-banging directly on the hard-disk, 
saves it and runs through the modified GC - how will joe honest user detect 
that change.  The CRC will say that all is well. 

False security is worse than no security in some cases?  

I don't think there is a good answer to this - just because GC is open source 
only makes the exploit easier to implement and detect.  With enough 
motivation, the bad guys could subvert any accounting package in the same sort 
of way, and how could you check if the version of whatever closed-source 
program you had actually matched the good guys intended source code? (and I 
don't want this to descend into open/closed source flame wars...)


0.02
Maf.