Re: i5/OS Encryption -- read trigger

The intent of the read trigger is to provide a user [the trigger] program the ability to know what data was passed to the application program requesting the read. Allowing the read trigger to also change the data vitiates the assumption by the application program that it is reading what is in the database file[.format.row] against which it was coded. The means provided to modify the data on read, is by functions coded on the SELECT; e.g. CAST, UDFs, DECRYPT, UDTFs, etc. -- and in the case of the non-SQL programs, whatever functions it desires to perform on the data after it is read in the defined format [or the program can reference a VIEW]. In this manner, the SQL request/program itself requests any modification to the data being selected, versus the SQL request/program seeing data which was modified by a possibly rogue read trigger.

Regards, Chuck
-- All comments provided "as is" with no warranties of any kind whatsoever and may not represent positions, strategies, nor views of my employer

jlowary@xxxxxxxxxxxxx wrote:
<<SNIP>>

Encrypting the data was not much of a problem. You can write a trigger program that will run when a record is added or changed in the file and have it do the encryption (because you can modify the buffer before it gets written into the file in this trigger). Decryption on the other hand does not work the same. We found that you can create a trigger for the read of the data, but even if the trigger program modifies the data it does not get passed to the program issuing the read! (double yuck!!) Seem the designers in their finite wisdom decided that no would be changing the data coming out of a file in a trigger. We were told by IBM that it works as designed and was not going to be changed (this was about 3 years ago, so I've not revisited this might be they have changed their minds). Any way long story short we were going to have to make modes to 175 vendor program that read this info so we could call a service program to do the decrypt, after each and every read in their software (triple yuck!!!).

Luckily the vendor was getting pressure from others and did their own encryption/decryption so we did not have to mess with this and then maintain vendor changes in 175 of there programs that we made mods to!!! Unless IBM has changed the ability of a trigger to update a read buffer before the program gets the data retrofitting this into a existing system requires a lot of for thought and possible some recodeing if you don't have standard I/O routines.

Anyway this is what we ran into back about 3 years ago.

<<SNIP>>