Voting RDS FAQ

Welcome to the Voting RDS FAQ. Below you will find answers to some commonly asked questions regarding the Voting RDS. If you cannot find your question, please feel free to contact us.

• How are the anomalies between distributions 03/07/2006 and 11/08/2006 explained?
• Is it true there were no submissions to the NSRL Voting project between October 29, 2004 and October 18, 2006?
• If there is a gap in submissions on the website, is it safe to assume that no submissions were received? If so, why?
• 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?
• Is it customary for a given ProductCode's baseline to change over time?
• 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?
• Does the NSRL execute the installation programs and scripts submitted?
• If not, how does one tell if an installer lays down the identical software components as the previous instance of the installer did?
• 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?

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:

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 vote history) 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 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). 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. Go here for the latest update.