Re: Script codes

From: David Jefferson <d_jefferson_at_yahoo_dot_com>
Date: Thu Jan 05 2006 - 22:16:59 CST

Section 6.4.e does not exist. But there is a 6.4.1.e, which is
surely what is intended. Here it is, in context:

6.4.1 Software and Firmware Installation
The system shall meet the following requirements for installation of
software, including
hardware with embedded firmware:
a. If software is resident in the system as firmware, the vendor
shall require and
state in the system documentation that every device is to be retested to
validate each ROM prior to the start of elections operations;
b. To prevent alteration of executable code, no software shall be
installed or resident in the system unless the system documentation
states that
the jurisdiction must provide a secure physical and procedural
environment for
the storage, handling, preparation, and transportation of the system
c. The system bootstrap, monitor, and device-controller software may
be resident
permanently as firmware, provided that this firmware has been shown
to be
inaccessible to activation or control by any means other than by the
initiation and execution of the vote-counting program, and its
exception handlers;
6-8 Volume I Section 6
Security Standards
d. The election-specific programming may be installed and resident as
provided that such firmware is installed on a component (such as
chip) other than the component on which the operating system resides;
e. After initiation of election day testing, no source code or
compilers or
assemblers shall be resident or accessible.

It does not make a lot of sense to me, i.e. I do not know what the
drafters of the "exception" listed in 4.2.2 could have intended by
referring to 6.4.1.e.


On Jan 5, 2006, at 9:09 PM, charlie strauss wrote:

> -----Original Message-----
>> From: Scott Brown <>
>> Sent: Jan 5, 2006 10:42 PM
>> To: Open Voting Consortium discussion list <ovc-
>> Subject: Re: [OVC-discuss] Script codes
>> The quoted section doesn't unconditionally prohibit anything. It
>> simply
>> prohibits certain types of development environments unless proper
>> precuations are taken.
> yes, okay I grant you that interpretation for the quoted section.
> But the prior sentence (quoted earlier but not in the section you
> are refering to) seems unequivocal:
> namely:
> ">> 4.2.2 Software Integrity
>>> Self-modifying, dynamically loaded, or interpreted code is
>>> prohibited, except under the
>>> security provisions outlined in section 6.4.e."
> I'm not sure what is is 6.4.e (I'm guess it's an exception for COTs
> or something)
>> -- Scott
>> On 1/5/06, David Jefferson <> wrote:
>>> I am not facile with Python. But my reading of these lines is
>>> that they
>>> require strong typing, including bounds checked arrays and
>>> strings, and
>>> disciplined object references (e.g. Java). Also, my personal
>>> interpretation is that whatever the main body of code is writen
>>> in, there
>>> cannot be a *second* level of interpretation, i.e. Python and
>>> Java would
>>> be OK by me as primary languages even though they are
>>> interpreted, as long
>>> as there were not another level of interpretation of some other
>>> language.
>>> But, of course, I am not an ITA.
>>> And if it were up to me these lines would seem to preclude C,
>>> because of
>>> the confusion between integers and pointers in that language does
>>> not allow
>>> any strong way of controlling pointer references; but I doubt the
>>> ITAs
>>> interpret it that way, or enforce it.
>>> David
>>> On Jan 5, 2006, at 7:52 PM, charlie strauss wrote:
>>> -----Original Message-----
>>> From: David Jefferson <>
>>> The prohibition on interpreted code is in section 4.2.2 of the 2002
>>> FEC standards.
>>> 4.2.2 Software Integrity
>>> Where the development environment (programming language and
>>> development tools)
>>> includes the following features, the software shall provide controls
>>> to prevent accidental or deliberate attempts to replace
>>> executable code:
>>> Unbounded arrays or strings (includes buffers used to move data);
>>> Pointer variables; and
>>> Dynamic memory allocation and management.
> _______________________________________________
> OVC-discuss mailing list

OVC-discuss mailing list

= The content of this message, with the exception of any external
= quotations under fair use, are released to the Public Domain
Received on Mon Jan 8 20:24:36 2007

This archive was generated by hypermail 2.1.8 : Mon Jan 08 2007 - 20:24:39 CST