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

[Mike or Penny Novack]

>>
> 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.