[Tfug] SQL database question

[Bexley Hall]

Hi, Jim,

--- Jim March <1.jim.march at gmail.com> wrote:

> I filed a public records request for those data
> files.  The county turned me
> down because Sequoia told them to - Sequoia wrote a
> letter saying that they
> embedded "program code" within the database, which
> in turn is proprietary trade secret of Sequoia.

Anyone can *claim* anything.  It's up to the sharks
to finesse what's real and what isn't...

> Now, voting systems have to be Federally certified
> to be legal in AZ.  I
> know a LOT about that process.  One of the rules in
> the Federal process, and
> it's "cast in stone", is a ban on interpreted code. 

Define "interpreted code".  You can move that
bar as high or as low as you want.  Without a
formal definition, I wouldn't venture an
"expert" opinion.

> The reason for the ban
> is simple: election software that is shipped into
> the field is supposed to
> match the hash-codes of the master set maintained by
> the Feds, and
> verifiably the same as what the testing labs
> reviewed.  There's also a need
> to make sure that voting system code, once shipped
> into the field, isn't
> modifiable by crooked elections officials or anybody
> else.

That doesn't rule out "interpreted code".  I can
build an application -- *any* application (including,
for extreme example, gaming devices -- which are
subject to *insane* regulation... "money" is far
more important to their owners than "voting
integrity" is to our lawmakers  :> ) -- that runs
*entirely* interpreted code and still make it
"immutable".

OTOH, I can take an application that is 100%
"compiled" and bastardize the hell out of it!
(I once earned some very nasty frowns at "sign-off"
inspection for a piece of IBM gear when the test
program popped up the message "Go for coffee"
instead of the original "Please wait" that it was
*supposed* to say  :-/ )
 
> So...if there's "program code" buried in the .SQL
> files, wouldn't it be
> interpreted, or could it be compiled objects?  Would

Depends.

And, depends on what you mean by ".SQL files".

The *database* can contain "code" in the form of
support for new data types, etc.

It can also contain SQL procedures (as well as
other "languages") written by the application
designer to act as triggers, et al.

The *queries* can also be viewed as "interpreted
code" if you want to be pedantic.  E.g., I can
essentially write an SQL query that says:

   if (vote_cast == DEMOCRAT)
       vote_cast = REPUBLICAN;
   return vote_cast;

> any such code, if it's
> there, be modifiable fairly easily?  Does it even

Yes and no.  You can add code to a database in
various ways and in various *forms*.  E.g., I could
write all the "business logic" in *C*, compile it
and then make those functionally *part* of the
RDBMS.

Or, I can write the same stuf in pl/SQL and let it
keep the appearance of "interpreted code", etc.

> pass a basic sanity check
> to have applications software embedded in an SQL
> database, or are they
> likely just blowing smoke?

You don't know for sure *what* they are doing.
You could, theoretically, store machine code
(or interpreted code) *in* the database as
"data objects" and craft your application to
fetch those objects and *execute* them (which
can, in turn, issue other queries in SQL or
whatever), ad nauseum...
 
> In the Diebold world, they did the same thing using
> MS's "object linking and
> embedding" (OLE) to stuff crap into MS-Access .MDB
> files.  But it was all
> hand-modifyable and hence in violation of the "no
> interpreted code" ban.
> 
> Thoughts?

<shrug>  Can't tell the players without a (the)
program.


      ____________________________________________________________________________________
Be a better friend, newshound, and 
know-it-all with Yahoo! Mobile.  Try it now.  http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ