On 13-Sep-2016 00:52 -0500, Walt Bennett wrote:
In a previous post I sought assistance with debugging a FieldProc
program, which worked very well, thank you.
First, I feel compelled to point out that the general topic in this
message [as implied also by the quite generic one-word subject line] is
_unrelated_ to RPG. The question is more appropriate on midrange-l; and
perhaps a response there would have come sooner.? Please post a new
message [with appropriate context for further discussion] on that list,
for any followup on the topic, unless something specific to the RPG.
Now that I am able to debug the FieldProc pgm, I find that it is
invoked even when I am doing an sql SELECT and even when I perform
DSPPFM from the command line.
If that were not the case, then things would be horribly wrong. All
interfaces to the [effective] /read/ and /write/ or /update/ methods
against the data *must ensure* the effect of consistently decoded->out
and encoded->in to maintain the data integrity. The DB2 for i feature
must invoke the FieldProc Program (FPP) everywhere that either of those
effects [i.e. encoding or decoding] is required, to ensure the data
integrity. And the FPP must be coded properly, similarly to ensure data
integrity for each of those invocations that are made by the DB; e.g.
and most importantly, the FPP must never mask the data when the DB
operation requires no masking.
In other words, any way in which I view the file, the data is
decoded.
Awesome :-) Seems everything [at least that which has been reviewed
so far] is found to be working correctly.
I've read an enormous amount of material on this subject and I
cannot seem to understand how I would be able to see the data in
encoded form.
The program[mer] gets to /see/ the data in encoded form; i.e. via the
FieldProc program, as what actually encrypts the original data that is
then passed to the DB to be stored in the TABLE. The programmer can
debug, log, etc., to view what was requested to get stored in the TABLE.
Outside of that program\logging, probably the most appropriate place
to allow\enable visibility to the encoded data is via the Display
Journal (DSPJRN) interface; noted again, explained further, later in my
reply.
Perhaps I simply need to better understand how decryption
works. It seems to be automatic.
My impression is that your understanding is quite on-track; in your
first go, the FPP makes the encryption and decryption /automatic/ and
/transparent/ [see this latter term referenced again later].
Wouldn't it be expected that the data cannot be decrypted by a user
if they lack certain permissions?
Yes. The implementation of who\why\when any read-request should be
allowed to _see_ the decrypted\decoded data, is probably the most
complicated part; i.e. the actual encryption\decryption are likely
offloaded to APIs that do all of that work, so that part should be quite
simple, by comparison.
The encrypted\encoded values are not generally going to be something
that is /viewed/; typically the encoded value would only ever be
generated by the FPP, and the encoded value would later be decoded [or
masked] by the FPP. So the _logical perspective_ is that what will be
viewed, is going to be one of *either* _a masked value_ [when the
presentation is to\for someone _unauthorized_ to see the fully decoded
value] or _the decoded value_ [when the presentation is to\for someone
_authorized_ to see the actual\fully-decoded\sensitive value].
Perhaps this is where masking comes in.
Exactly.
First, for those users lacking permission; for whom either a
partially decoded view of the data might be offered, or something
entirely unlike the actual data might be presented such as the special
value *NOTAVL to suggest to the reader that the datum is "not available,
per being something outside their purview"].
Second, and as I will explain later, for the ability of someone like
the programmer to see the encrypted\encoded data [without having to use
debug or some program-logging technique]. This is the part I think
maybe is not fully understood [as inferred from "cannot seem to
understand how"; and quite understandably IMO, as this is probably not
something easily intuited.
The system I am using requires a PTF cume update in order to support
masking.
So again, awesome; seems as though everything is fine, and completion
of coding\debugging awaits the additional underlying support by the
database for the masking. To be clear, until that capability is made
available for the masking [via the PTFs in this case], there is no
ability to effect anything other than the encode->in and decode->out in
the FPP. That lack of support however, does not inhibit the ability of
the programmer to use logging or debug to /view/ the encoded data in
whatever way and whenever they choose.
Would masking prevent the decrypted data from being seen by a user?
Normally, that would be the purpose of masking; i.e. selectively
mask, by some pre-defined [lack of] permissions, as already alluded in a
prior question.
Masking is, well, masking; concealing or disguising the value, either
to obfuscate for or to quite conspicuously signal to, a reader, that the
value being presented is not what is the actual value [that was stored
in the database]. And FWiW, the FPP would offer a value via the masking
support, something that should be obvious to the reader as not being the
actual value; i.e. showing a gibberish-value [e.g. '#$*&^@#' in place of
the actual value is likely to cause problems [for business processes],
as contrasted with the presenting of a value like the character string
'**sensitive-data**'.
For example, instead of seeing an actual stored credit card number, a
reader [e.g. a customer support representative] might be presented with
asterisks displayed for all but the last-four digits [as what is
typically used] to assist a rep to identify\confirm for a customer,
which of their cards\accounts is being discussed. In this example, the
masking serves to conceal [a majority of the] sensitive data\details
that are not relevant\necessary for the customer rep to know\see, yet
still enable the rep to do their job.
Consider [¿not intuitive?], because the /masking/ processing enables
the FPP to generate something *other than* _the decoded value_, that
same mask-processing can be utilized to present _the encoded value_.
However there is an inherent difficulty in doing that with the general
/read/ interfaces; typically, the stored-as-encoded value is larger than
the presentation-size, and therefore there is _no room_ in the
presentation space\layout to present the value stored internally -- and
the encoded value is usually binary as well, for which typically the
best way to display the binary data would be as hexadecimal digits, for
which even more room is required. Yet:
Note that the DSPJRN allows viewing the amount of data for the
internal-form of the data [vs external presentation-size] and enables
requesting to see the data presented as hexadecimal digits. Thus when
invoked by DSPJRN and the user invoking has the deemed-appropriate
permissions or otherwise\additionally has set some effective /debugging/
flags [e.g. perhaps an environment variable setting indicating that
seeing the encrypted\encoded value is desired], then the
masking-processing of the FieldProc could be utilized to return the
internal-form of the data [i.e. the not-yet-decoded and unmasked data].
If someone can point me toward relevant material, it would be
greatly appreciated.
With the first iteration of FieldProc, indeed, there existed only
support for /transparent/ encryption and decryption; i.e. without any
ability to mask [instead of decode->out. Eventually support was added
for the /conditional masking/ for selectively offering mask->out vs only
decode->out. See my reply in the following discussion, noting
especially, the final comment redirecting to the two articles wherein
there is a clear distinction made between the two levels of support for
the FieldProc program, /only-transparent/ and /masking-enabled/:
Subject: Re: FIELDPROC Issues
[]
http://archive.midrange.com/rpg400-l/201504/msg00243.html
Those articles, and perhaps more, should be capable of being located,
with a web search on the tokens "FieldProc" "Milligan"
midrange.com
