|
NIST
& HAVA
NSRL
Voting Project
NSRL
Project
Privacy Policy/Security Notice
Disclaimer | FOIA
NIST is an agency
of the
U.S. Commerce Department's
Technology Administration.
To ensure you are viewing the most recent focused release of voting
software data, click
here.
Last
updated:
April 3, 2008
|
FAQ: Voting RDS
April 3, 2008
Q1:
How are the anomalies between distributions 03/07/2006 and 11/08/2006 explained?
Answer:
There are three intentional differences between the 20060307 and the 20061108
distributions that are known to us. The changes are explained here for historical
clarity. However, since each voting distribution produced is a cumulative
superset (which supersedes all previous distributions), users should always
use the most recent distribution.
First, during the above time period, the NSRL project
integrated the voting-specific handling into the main RDS production pipeline.
It had previously been handled via a separate production pipeline. This
integration required a re-assignment of database keys (a.k.a. ProductCodes)
for some of the voting products into the main database key-space. A comparative
analysis between voting distributions might appear to show missing products
(between distributions 03/07/2006 and 10/03/2006) whereas no products
were missing at all and the files were all actually present just with
new database keys assigned to them. The re-mappings of ProductCode key
ranges were:
| From |
To |
| 9000-9032 |
8295-8327 |
| 9038-9067 |
8328-8357 |
| 9069-9089 |
8358-8378 |
These mappings are provided for user information
only. Voting RDS users should not try to use the ProductCode key as a
persistent identifier.
Second, the NSRL periodically re-processes products
for the purposes of verification as well as to utilize improved processing
technologies. All voting-software products were re-processed when integrated
into the main RDS production pipeline. This reprocessing took advantage
of “smarter” algorithms which harvested additional hashes.
Finally, prior to the integration, we found that
the separate pipeline produced records where the contents of the filename
field were placed in the neighboring database record instead of their
own. This off-by-one filename effect was identified and fixed in the 20061003
release. All voting RDS distributions since (and including) 10/03/2006
are free from such anomalies and include all file profiles collected to
date. All hashes produced at all times have been valid.
Q2:
Is it true there were no submissions to the NSRL Voting project between
October 29, 2004 and October 18, 2006?
Answer:
The table of previous releases (see http://www.nsrl.nist.gov/voting)
lists the submissions which were received by the NSRL project during this
time period.
Q3:
If there is a gap in submissions on the website, is it safe to assume that
no submissions were received? If so, why?
Answer:
Yes. It is our policy to process any newly received voting software submissions
as soon as possible after receipt. This process usually takes two weeks.
New distributions are generated and posted to the NSRL voting website upon
receipt of voting software submissions as well as quarterly for each major
RDS release.
Q4:
Some states claim to have hash values of the software components of their
systems that are approved for sale in those states. How are these state
libraries of software components incorporated into the Voting RDS?
Answer:
In the past, all voting software distributions sent to the NSRL occurred
on a strictly voluntary basis. Under VVSG 2005 (Volume I, Section 7.4.4.d)
it is mandatory that voting software vendors provide the NSRL with software
for all new systems that are certified to VVSG 2005. Voting software vendors
may submit software for old voting systems (certified to pre-VVSG 2005)
to the NSRL on a voluntary basis. States are also permitted (but not required)
to submit voting software to the NSRL.
Q5:
Is it customary for a given ProductCode’s baseline to change over time?
Answer:
Yes. The baseline set of files for a given ProductCode in the Voting RDS
may change over time even if the ProductCode itself remains the same. This
typically results when products are re-processed with improved unpacking
technologies which may have been previously unable to unpack certain kinds
of archived, compressed, or otherwise embedded files. Such periodic re-processing
generally yields more files for a given ProductCode if there were any files
previously inaccessible to our unpacking systems. Also, since the ProductCode
is merely a database key, it is occasionally subject to change (see #1).
Such a change fully preserves integrity of the metadata and hash values
for each file.
Q6:
How can one perform a baseline audit of a voting device (a.k.a., Physical
Configuration Audit (PCA)) using the full set of NSRL Voting distributions?
Answer:
The NSRL does not provide guidance on how to audit voting systems. We only
provide the database of collected information (a.k.a. the Voting RDS). It
is informative to remember that each Voting RDS distribution is cumulative
and supersedes all previous voting distributions.
Q7:
Does the NSRL execute the installation programs and scripts submitted?
Answer:
Sometimes. The NSRL uses an automatic process to "unpack" voting software
submission files. Sometimes a voting software vendor requests that we install
a given submission and provides installation instructions. In such cases,
the installation procedure is followed and the installer as well as the
installed files are processed by the NSRL. However, the list of systems
for which the NSRL has provided this step is very small. They included "eSlate
3.1", "eSlate 3.3", and "eSlate 3.4".
Q8:
If not, how does one tell if an installer lays down the identical software
components as the previous instance of the installer did?
Answer:
Generally, if the hash values for a previous installer instance match exactly
those of a given installer program, one may have a high probability of any
installed files matching. However, if the installer operates as a script-driven
system that interprets a companion installation script, its hash could plausibly
not change (while the script file(s) would be expected to change). The most
complete approach is to match as many files as possible in the target system
with the file profiles from the Voting RDS.
Q9:
Why are there 5 files from productCode 8392 that were in the Voting RDS
(VRDS) for 2.17 that are not in VRDS 2.18 or VRDS 2.19?
Answer:
The reasons for this are as follows. For this particular software package
(ProductCode=8392), the vendor originally sent several versions of software
on one piece of media and it was processed automatically - thus placing
all these versions under the single ProductCode. As noted in the NSRL
for Voting FAQ, Question #7, occasionally the voting software
submissions are accompanied by manual installation instructions prior to
processing. The vendor contacted us communicating that they had intended
for each software version to be listed separately (with separated ProductCode
numbers). With these updated instructions, we performed the manual installation
steps before automatically processing each software version independently.
Each of the 5 noted files is essentially an archive of its contained files
for the respective software version, and thus, all of the contained files
were appropriately processed into the newly allocated ProductCodes (as noted
on the history page at http://www.nsrl.nist.gov/voting).
However, the base archive files were not included at that time. We have
noted this and reprocessed them appropriately making sure they are included
from now on. The latest update with the 5 files included may be accessed
at http://www.nsrl.nist.gov/voting/20080403/VoteRDS20080403.zip.
|
