Re: [OVC-discuss] Something really big: Sequoia source code, free to download and study, no NDAs.

From: Charlie Strauss <>
Date: Thu Oct 22 2009 - 01:59:24 CDT

Evidently my comments on if this was on a voting machine need to be
ammended. From you reply I now have come to understand that the
strings were extracted from tabulator code not from voting machine code.

I think my comments however should still apply.

the central question is, does the tabulator contain a SQL command
parser and interpreter? if it does not then having SQL instructions
in a program doesn't mean that code can be run since the interpreter
needed is missing. Right?

The other points I was making had to do with the possibility SQL code
might be example or BLOB-like stored procedures, not code that can be
executed. But just to facilitate people who want to use the data.

Finally the rationale for storing both raw data and data access
methods as sql instructions in a database is to hide the
implementation of the data storage like one usually does with most
objects. You provide accessor methods to query the stored data.
Sure, as you point out the data may be stored in known formats like
integers, but that does not mean you don't want to hide this
implementation. if you provide accessor methods in stead as the
interface, then later you are free to change the implementation of the
storage in some future edition of the code.

Anyhow, I'm not saying this is why they did it. I'd just like some
hints that these ideas might be ruled out.

On Oct 21, 2009, at 11:51 PM, Edward Cherlin wrote:

> Charlie, our concern is not whether this SQL is on the voting machine
> (unless the Microsoft SQL server is also present for some bizarre
> reason), but what it is doing in the results database, which is
> unquestionably processed using the database server software.
> o Does the SQL code present correct data for queries, or can it skew
> election results?
> o Can it be changed on the fly to give incorrect results?
> o Is is presence legitimate or not under FEC rules?
> On Wed, Oct 21, 2009 at 19:45, Charlie Strauss <>
> wrote:
>> Jim, I don't want to be an apologist for Seqoia, but I would like
>> to make
>> sure of what you are confident about and what you are not confident
>> about.
>> Now as I understand things you are using the unix "strings"
>> commands to grab
>> text looking segments of binaries. You are not for example simply
>> opening
>> text files and finding plain text.
> Correct. However, we can also open the binary files in certain text
> editors and examine the context of each string we find.
>> It's conceivable then that these curious text sequences are not
>> actually
>> things that a voting machine executes but are there for some latent
>> or
>> deliberate reasons.
> They are in the results database, and should never be on a voting
> machine.
>> for example. suppose that the voting machine itself has no command
>> interpret for the text SQL commands you found. But suppose that
>> these lines
>> of code are intended to be written out by the voting machine into
>> headers
>> and instruction files that accompany the data files.
> No, they would be written on the machine where the tabulations are
> done.
>> I sometimes do this in
>> my own code (admittedly rarely). I will write a comment string at
>> the top
>> of the data file that gives examples of how to parse the data that
>> follows
>> this header. One can imagine giving explicit code in such a header.
>> Another possibility is that these are like oracle "blobs".
>> executable
>> command sequences stored in a data base that could be executed if a
>> suitable
>> interpreter existed.
> Yes, up to a point. That point is whether this interpreted code is
> legal, where compiled blobs seem much more likely to pass that test.
>> This is how one often stores an "object" in a
>> database system. It does not mean the interpreter is present.
> The only reason to use a database storage format is to load it into a
> database instance, in this case to tabulate the vote counts and get
> election results, or for auditing.
>> it means
>> some other program (not in the voting machine itself) could
>> retrieve the
>> Blob and execute it on some data it also retreived. this technique
>> is very
>> frequent. it allows one to store data in a data base without
>> having to give
>> a specification of it's storage format. instead you store the data
>> in a raw
>> unspecified format and then supply an executable program that
>> allows queries
>> on that data.
> This should not apply. This is a voting database with formats known in
> advance. The source data consists entirely of integers, although the
> software could conceivably calculate something else from them, such as
> percentages.
>> Another possibility is that these are just accidents. Maybe some
>> files that
>> were left in some directory, perhaps there for other purposes, just
>> got
>> copied onto the voting machine along with the real code.
> No, this is a standard database backup format, where SQL is normal.
>> A final possibility is that it's just Chaffing from seqouoia. extra
>> obfuscating crud they shove into code to make disassembly or
>> analysis really
>> hard.
> They appear not to have done any obfuscating. We originally thought
> that some header data were missing, but in fact the file loads into
> the software without error, and can be queried normally.
>> The real smoking gun is if there is a SQL interpreter on the voting
>> machine.
>> has that been found?
> There would be no excuse for that, but also no reason to do it, and
> significant licensing expense. The voting machine deals with one
> integer per contest. The file would be more complex with ranked
> preference voting, but we aren't there yet, and even there we are
> dealing with sequences of integers of known length.
>> can the other possibilities be discounted?
> Working. Jim?
>> On Oct 20, 2009, at 4:17 PM, Jim March wrote:
>> On Tue, Oct 20, 2009 at 3:03 PM, Edward Cherlin
>> <> wrote:
>>> Can we get out a press release?
>> Well...we want to get a lot of attention, but not necessarily press
>> just
>> yet. We were hoping that the first step will happen fairly
>> quickly: proving
>> vandalism of the data files instead of redaction. If that can be
>> confirmed,
>> cool:
> OK, not a problem, as it turns out.
>> 1) Mainstream newspapers will be REAL interested, as they are with
>> any
>> public records related problem.
>> 2) It really hurts Sequoia on multiple levels: makes it much harder
>> to
>> challenge what's going on in court for example, under the "unclean
>> hands"
>> doctrine. It will also make it much harder for them to screw with
>> additional public records requests.
>> So we wanted to wait to hit the newspapers and such until we can
>> prove the
>> vandalism issue.
>> Go ahead and get it on Daily Kos though, in the interest of
>> attracting geeks
>> :).
> Google News shows
> dKos, Slashdot, HuffPo, KESQ, Techdirt,, ITwire, Bradblog.
> That's three that we posted ourselves, and five that picked up the
> story. There may be others.
>> Jim
> --
> Edward Mokurai (默雷/धर्ममेघशब्दगर्ज/
> دھرممیگھشبدگر ج) Cherlin
> Silent Thunder is my name, and Children are my nation.
> The Cosmos is my dwelling place, the Truth my destination.
> _______________________________________________
> OVC-discuss mailing list
> By sending email to the OVC-discuss list, you thereby agree to
> release the content of your posts to the Public Domain--with the
> exception of copyrighted material quoted according to fair use,
> including publicly archiving at

OVC-discuss mailing list
By sending email to the OVC-discuss list, you thereby agree to release the content of your posts to the Public Domain--with the exception of copyrighted material quoted according to fair use, including publicly archiving at
Received on Sat Oct 31 23:17:06 2009

This archive was generated by hypermail 2.1.8 : Sat Oct 31 2009 - 23:17:11 CDT