[Tfug] Any SQL gurus out there?

Jim March 1.jim.march at gmail.com
Fri Oct 26 11:24:00 MST 2007


Quoting Ronald Sutherland:

>>Does the CPU not interpret machine instructions (is that not code)? I'm
thinking the feds just prevented the use of computers with that rule.
But what pisses me off is the line of thought that a binary blob is some
how safer and more verifiable than a script. The blob was compiled from
something, that can be looked at and studied to figure out its intent,
its called source. The source can be held in a version management system
to keep an audit trail of any changes, but once its compiled the blob is
difficult to trace back to the source, you need the exact libraries it
was created with, in other words your locked out of updates to most
everything. I've more than once compiled the same program and gotten
different blobs, which makes the compiler setup a critical step in the
verification process. If I have a script I can difference it directly
with a version management server and see if its the same. I can also
look at it directly as source to evaluate intent. If the scrip is self
modifying I would hope that intent is found (add eyes to make things
clear), this ever present desire to hide all sorts of stuff is a wrong.
The scrip interpretor could be modified to do tricky stuff to a scrip
that makes failing things pass but the script itself can run self test
and keep track of the interpretors (md5sum). Scrips can also be provided
on read only media, thus gaining readability and verifiability with the
original source while retaining the ability to self identify known good
interpretors.<<

A very interesting point.

What they're trying to do with these binary blobs is prevent
field-modification of code.

The Federally approved test labs are supposed to check the source
code, do their own compile, make sure the binary blob is legit, hash
it and publish the hash.  That way what's in the field at the county
level can be pinned down as being the same as what the labs checked
months or years earlier.

Now, there's ALL kinds of reasons to suspect (hell, prove) that the
labs are doing a terrible job.  Two of the original three approved
labs have already been fired for poor performance with two new ones
grafted in.

An open source model is the way to go here.

BUT!

Until we get open source, making sure people inside the Pima elections
division don't tweak code themselves or import tweaked code is a good
thing.

And that model of "freeze the binaries with hashes" can still be
applied in an open-source world: publish the source along with
compiler/system information, and anybody can check the code, do a
compile and find the hash - then cross-check that hash against
field-installed code.  A bit kludgy?  Maybe - but you also don't have
to check sources in EVERY county.  You just have to check source code
once (for a given product) and then publish the "known good hashes".

Remember that most of your available election integrity volunteers are
techno-turnips.  A useful percentage can be relied on to run a
hash-check script and get a "yay or nay answer" but getting enough
geeks together to check sources in 3,000 election agencies
nationally...FORGET IT!

We can also get any number of situations where we don't necessarily
agree with the rules ourselves, as with the Federal certification lab
system, but we can still cite violations of those rules against a
really screwed up company like Diebold.

Jim March




More information about the tfug mailing list