"correcting" transactions <<how to approach this>>

[J. Elfring]

Hello GC list,

first of all, let me introduce myself. My name is Joerg, coming from
Germany and using GC for about five years to keep track of my personal
finances. It works quite well and gives a real good insight of what is
going on, although a certified accountant might not like what I am doing
there ;-).
I just registered for the list as I would like to contribute to this
discussion.

For my understanding, there are two topics mixed up here. First one is to
"make is easier to not mess-up the data" which is basically the same as
"make it harder to tamper with the data". The other topic is to "give a
qualified prove that the data was not tampered with". (as already said)

About the first on: A very big Thank You! for the
lockout-after-n-days-function. I only just discovered it yesterday, but I
am sure would have saved me some very nasty work searching for imbalances.
Of course there could be some more function of that type or things could be
different. But after all, most things will not make it impossible to mess
around.

About the second topic: if you really need that kind of verified data, you
will need two things: an audit-trail and the certificate, from someone
trustworthy, that things were not altered after being written down. Also,
you have to keep in mind that you will need this for a lot of things
besides the GC file like actual invoices and so on... (Finally you need
someone to verify that the documentation matches the actual business - but
that's another topic).

So why not do the following: Turn off the backup-, logfile- and compression
features and save the gnucash file as plain xml. Then you add the necessary
other documents and put it all under git version control. This will give
you a crypto-level integrity of all your commits and even a xml-diff based
audit trail. Finally, you can send the hashes of your repository to a
qualified timestamp service (not tested) and receive a qualified
certificate about your data to a certain time.
This might be a little bit confusing for users without programming / git
experience. But I think it is a functional toolchain. And mid-term some
hooks inside gnucash to trigger git or a diff-to-transaction viewer might
be possible.

Comments are welcome!

Cheers, Jörg



2014-02-23 14:41 GMT+01:00 Mike or Penny Novack <stepbystepfarm at mtdata.com>:

>
>
>>>  What you want is called fake security. At first glance what you want
>> seems reasonable...   but in reality, any technical person can alter the
>> computer program to make the output look exactly as they please.
>>
>> The way to get security would be to have read only media at certain
>> checkpoints in time (say at the end of every month) and then have your
>> audit person compare the current output with them.
>>
>> And as an accountant here is my take on accounting principles, it's a
>> load of crap. Accountants try to pass this stuff as natural laws like the
>> speed of light etc. Where really accounting is simply a business tool to
>> help the business owners make decisions. Not something to provide
>> accountants with government mandated jobs.
>>
>>
>> Lawrence
>>
>
>
> Lawrence understands the real issues here (and what a real solution might
> look like)
>
> But for those who still want program modifications to accomplish certain
> "security" features, let me make a suggestion how to possibly proceed. A
> good deal of the reason your suggestions are being rejected is that you are
> not being clear enough at the "business level" what the changes are to
> accomplish and what the limitations might be. In other words, FIRST settle
> that without any reference to how might be implemented and IF could be
> implemented (without the limitations).
>
> For example, a request worded "provide a check to prevent alteration" (by
> a person entering data) with the limitation "unless that person were a
> competent programmer" is a VERY different request than has being made. In
> the "real world" a project begins with discussion meetings of the problem
> at the business level, no reference to how/if could be implemented,
> although wise to have a systems analyst sitting at that meeting, at the
> moment wearing his or her "business analyst" hat.
>
> I'm sorry, but unless you have a great deal of programming experience you
> are not a good judge what programmers could or couldn't do.  Solutions that
> look good to you (for example that check sum/encryption scheme) might not
> block a programmer <<who would NOT have be able to crack the check
> sum/encryption algorithm to alter the file, just be able to create a new
> valid check sum/encryption for the altered file>>  Leave the "would this
> work" to those of us whose line of country it is.
>
> There ARE differences in the world of open software because how a program
> does everything it does is trivially available to a programmer. Even one of
> just average competence. In this regard proprietary closed software is
> somewhat safer. Not that a really skilled/experienced programmer armed with
> some specialized program analyzing tools like "monitors" couldn't create a
> modified version but that's NOT the same risk <<it might take months of
> work time and we'd be charging perhaps $100/hr for LEGAL work* of this
> sort. I have no idea how much to tempt one of us for an ILLEGAL project>>
>
> Michael
>
> * For example, a business needs to change the behavior of some routine of
> its software that has been in production for decades but the source code
> has been lost. Done that in my day. Extract the component from the run
> exec, disassemble it, hand translate the gobblygook output of a
> disassembler into human readable form (THAT takes lots of experience and
> sliding around slips of paper till the displacements make sense), possibly
> translating the human readable assembler to its high level language
> equivalent (again a lot of experience with the language to recognize what
> statements of that language under that compiler would have resulted in that
> assembler code), making the desired change (the trivial bit),
> reassembling/recompiling, and inserting this back in the run exec with a
> link editor.
>
> The "monitor" tool to which I referred earlier would come into play if not
> known WHERE in the run exec this little bit was. If one could arrange two
> runs under the control of a "monitor", one in which it was know some code
> was not executed and one in which it was know that code was executed, the
> differences in the monitor outputs would locate that code. And yes,
> precisely because I know how to do that, I also know how to design a bit of
> code to make it hard to find that way.
>
> The point I am making by describing that is we perhaps don't have to worry
> that an embezzling bookkeeper would have that level of programming
> skill/experience. If they did, why working for a bookkeepers pay? But with
> open source the high level language code is in plain view.
> _______________________________________________
> gnucash-user mailing list
> gnucash-user at gnucash.org
> https://lists.gnucash.org/mailman/listinfo/gnucash-user
> -----
> Please remember to CC this list on all your replies.
> You can do this by using Reply-To-List or Reply-All.
>