Re: Is Open Source Enough?

From: Richard C. Johnson <dick_at_iwwco_dot_com>
Date: Sat Sep 08 2007 - 11:28:53 CDT


The OVS solution includes innovation in protection against a wide variety of threats. Any such solution can always be improved, and OVS is open to both criticism and suggestion. OVS has not yet reached the point where it has had certification or live trials of its software, which, as you point out, are proper precursors to general adoption. Until that time, voluntary offers of assistance are in order.

The expectation of threat modeling is not that it has all the answers. Rather, it is yet another analytical tool to help achieve overall goals of increased security, transparency, and quality. The main OVS security feature is the simplicity of its code, based as it is on Java and XML.

We have initiated several university-related contacts, one of which may bloom into the relationship you recommend. Again, OVS welcomes offers of both critical examination of the OVS architecture and code as well as actual assistance writing code. Almost all of the OVS critical code has been written, but the integration task is substantial. The code itself is almost all Java and XML, built around the structures of the OASIS Election Markup Language. We have 3 people working right now on documentation and test planning, while our final coding projects move forward; more are welcome. Any interested person is invited to write to: (OVS CEO) or (OVS CTO).

OVS is a collective enterprise, based on community effort and unpaid volunteer coders. OVS has zero proprietary interest in or claim to the code it is building. All of it is destined for free distribution under GPL. Please feel free to visit and see for yourself what security features and architecture may be in progress.

I like your ideas about test...I have argued repeatedly that regression testing is needed for re-certification of "fixed" problems in voting applications.

-- Dick

Brian Behlendorf <> wrote:
On Thu, 6 Sep 2007, Arthur Keller wrote:
> So should we be considering threat models and alternative architectures?
> Should we be doing threat analysis on Open Voting Solutions' software? Or is
> the fact that Open Voting Solutions' software is open source enough to give
> us confidence that it is a secure and reliable system merely awaiting
> (known-to-be flawed) certification process?

For the sake of the reputation of the OVS solution, I would assume they have
already and are constantly thinking of new ways to subvert the system. I would
assume they have run Agitar or a similar input-fuzzing tool or static analysis
tool against the software to look for exploitable memory leaks or logic errors.
I would assume they have a public list, as part of the development process, of
secure coding practices (such as "never trust external input" and "no casts
ever in C") or are have a wishlist of same with a timeline for applying them.
But time is always a limiting factor and writing secure code is hard, so when
holes are found none of us should be surprised; instead of judging the OVS
software by how perfect the code is, the vendors deploying it should be judged
by how quickly they can fix a hole once discovered.

OVS or other vendors of open source software should also be looking for
non-critical environments to test their solutions out - school elections?
survey kiosks? They should be looking for computer science professors at
community or state schools willing to study the software as both an example of
a voting system and for other potential holes that only a highly motivated and
caffienated 17 year old can find. :)

But never rely on the license on the code to have any significance prima facie
to its security. All it can do is unleash potential.

> My own suggestion is to proceed with certification of OVS' system
> while we develop threat models and new architectures that vendors
> (particularly OVS) can adopt.

I have not looked at the OVS software so I can't comment on its maturity, but
if it's something that you believe is ready for production use, and ideally has
already been used for real or semi-real elections successfully, then go for

My worry about the use of the word "threat modelling" is that it makes it sound
like there's a formal process one can go through to articulate every possible
attack vector, and by blocking each you then have provably secure software. Or
that there's a particular software architecture, or even language, that
guarantees secure software or makes it hard to write insecure software. I
would wish to disabuse you of those notions; new ways to attack software emerge
all the time, and as stated before a secure elections process shouldn't depend
on inexploitable software anyways.

> Some on this list have advocated open test environments. How do we get
> there?

It'd be great if the certification process were transparent, so it was
understood what was being tested. That could even lead to the development of
an automated test suite for some or all of the certification process, that
could be run after any source code change to make sure the system remained in a
certifiable state.


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
= The content of this message, with the exception of any external
= quotations under fair use, are released to the Public Domain
Received on Sun Sep 30 23:17:08 2007

This archive was generated by hypermail 2.1.8 : Sun Sep 30 2007 - 23:17:20 CDT