WinEDS does not Comply With 2002 VVSG

On Tuesday, March 13, 2006 I was finally able to confirm that WinEDS is routinely shipped with source code and a compiler and the presence of the compiler is required by Sequoia. The source code is the SQL programming in the Transact-SQL language and the compiler of this source code is Enterprise Manager.

During the audit of the Pinellas County, Florida primary election last year, it was discovered the county was using to Enterprise manger to directly manipulate the Microsoft SQL database under the WinEDS application. The question which I could not confirm until yesterday was whether Sequoia REQUIRES the purchase and installation of the SQL compiler, Enterprise Manager, or not. The purchase orders from Waukesha County, Wisconsin confirm Sequoia requires the complete set of Microsoft SQL database administration tools (Eneterprise manager, Query analyser, etc.) be installed as a requirement of WinEDS. In Waukesha county, the WinEDS application runs on the same physical machine as these database adminstratin tools.

This is a violation of 6.4.1(e) or the 2002 Voting System Standards. Here is the letter I sent to the county clerk and the staff of the Wisconsin State Elections Board.

WinEDS violates both the 2002 VSS¹ and 2005 VVSG² because the presence of Microsoft Enterprise Manager constitutes a compiler of the SQL programming invoked by WinEDS. The presence of compilers and programming source code is expressly forbidden by both the 2002 and 2005 versions of the national standards. Further, I speculate, none of the SQL programming source code incorporated into the WinEDS application was submitted for software review by the ITA labs.

Here is a comparison of Access 2000, Microsoft SQL Desktop Edition, and SQL Server Enterprise.

http://msdn2.microsoft.com/en-us/library/ms811092.aspx

The relevant excerpt for MSDE and the SQL programming in a stored procedure is:

Stored procedures exist as permanently compiled objects in MSDE. Precompiling reduces the overhead required for execution. Stored procedures can accept and return data. Stored procedures can also be used to group complex SQL statements. The contents of stored procedures may be hidden from applications.

In Microsoft’s own words MS SQL Server stored procedures, user-defined functions, and triggers are a programming language; Transact-SQL³. http://msdn2.microsoft.com/en-us/library/aa214299(SQL.80).aspx. The relevant excerpt is:

Stored procedures in SQL Server are similar to procedures in other programming languages in that they can:

• Accept input parameters and return multiple values in the form of output parameters to the calling procedure or batch.

• Contain programming statements that perform operations in the database, including calling other procedures.

• Return a status value to a calling procedure or batch to indicate success or failure (and the reason for failure).

You can use the Transact-SQL EXECUTE statement to run a stored procedure. Stored procedures are different from functions in that they do not return values in place of their names and they cannot be used directly in an expression.

I will put aside for the moment the question of whether the SQL programming source code of WinEDS was ever presented for source code review the ITA testing labs as required by the 2002 and 2005 Voting System Guidelines. The presence of Microsoft Enterprise Manager is a separate violation of both the 2002 and 2005 Voting System Guidelines because the presence of the Microsoft Enterprise Manager on the WinEDS server is a violation of paragraph 6.4.1(e) of the 2002 VSS (http://www.eac.gov/election_resources/v1/v1s6.doc) and paragraph 7.4.1.(e) of the 2005 VVSG (http://www.eac.gov/VVSG%20Volume_I.pdf ). The cited paragraph reads (emphasis mine):

After initiation of election day testing, no source code or compilers or assemblers shall be resident or accessible.

The presence of Enterprise Manager allows for the examination, alteration and recompilation of the SQL programming of the stored procedures, user-defined functions, and triggers used by the WinEDS application. In Waukesha, Enterprise Manager is both resident and accessible.

The application code in WinEDS executes whatever SQL programming is behind the name for the stored procedure regardless of whether that SQL programming is the same as the SQL programming initial installed or SQL programming which has been altered between the time of installation and the time the procedure name was invoked during the administration of an election. The technical term for this feature is late-binding⁴. Here is Microsoft on the topic late binding of SQL programming: http://msdn2.microsoft.com/en-us/library/ms191436.aspx. The relevant excerpt is: (emphasis mine)

They[,stored procedures,] are named code allowing for delayed binding.

This provides a level of indirection for easy code evolution.

Evolution here means changes to the behavior of WinEDS AFTER state certification.

What is particularly problematic with WinEDS installation of Enterprise Manager is that it is completely unnecessary. Either Microsoft SQL Desktop Engine or its replacement, SQL Server 2005 Express Edition Overview⁵, could be used instead. The use of either of these other MS SQL Server compatible options would prevent the SQL programming of WinEDS to be changed in the field. This is because the SQL programming would be pre-compiled in Oakland, CA and an on-site compiler (Microsoft Enterprise Manager) would be unavailable in Waukesha, WI.

1http://www.eac.gov/election_resources/vss.html

2http://www.eac.gov/vvsg_intro.htm

3http://msdn2.microsoft.com/en-us/library/aa299742(SQL.80).aspx. Notice particularly the inclusion of IF.. ELSE, WHILE, CONTINUE, BREAK and EXECUTE programming elements.

4http://en.wikipedia.org/wiki/Name_binding

5http://msdn2.microsoft.com/en-us/library/ms345154.aspx