Re: _cipher API vs Qc3Encrypt/Qc3DecryptData vs SQL

Chuck,

With all due respect, I disagree.

1) Does the official SQL state that a read trigger may only be used as an auditing function, thereby there must be a requirement to prevent changes to the buffer?

2) Using your logic, all other applicable triggers (add and update) should also prevent buffer updates. Since that is not the case, I believe that a read trigger should allow the same capability.

3) As I pointed out in my original post, a read trigger would be the only way to implement encryption without application program changes.

-mark


At 3/26/08 07:19 PM, you wrote:

A UDF [User Defined Function] is what is used to redefine output [to
a program] reading data from a database file. Use the correct tool for
the requirement.

The Read Trigger is used for auditing what was passed to the program
that issued the read request. If the Read Trigger could change the
data, then what was passed as data to the trigger for audit does not
match what was sent to the program; function defeated. Also IMO IBM
would almost have to refuse to ever investigate any problem where any
Read Trigger was involved [if ever changing the buffer were allowed],
except under a paid consultancy. Non-SQL trigger programs already were
costly, to the point where many inquiries as suspected defect were
effectively forced through ConsultLine before being /proven/ not to be a
usage error; in my experience over 95% were usage problems.

At least UDF enforces well-defined structure\typing whereas a read
trigger could rewrite the output from the following request to return "A
BUNCH OF GARBAGE" instead of "SIMPLE", either on purpose or by an error
in coding:
SELECT VARCHAR('SIMPLE') FROM SYSIBM.SYSDUMMY1

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

M. Lazarus wrote:
>
> No, it would not defeat the purpose of the encryption at
> all. Since it's a trigger I would have the option of adding my
> application logic to allow only those authorized.
>
> Also, if the tape containing the DB file disappears, the raw
> data is still encrypted.
>
> It would be a *vast* improvement over what we have now. Currently,
> the file format must change. Therefore, in some way, the application
> must change. A read trigger would allow me to keep the same file
> format by separating the encrypted field(s) into another file and the
> trigger would decrypt the data if allowed and would map the decrypted
> data (or even some error text!) back to the triggering program's
> input buffer. The original application need have no knowledge that
> anything different happened since encryption was implemented.
>
> I don't really understand why IBM imposed this limitation.

--
This is the RPG programming on the AS400 / iSeries (RPG400-L) mailing list
To post a message email: RPG400-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/rpg400-l.