RE: Programming languages and trojans

From: Arnold Urken <aurken_at_stevens_dot_edu>
Date: Wed Apr 21 2004 - 13:47:11 CDT

LP,

 

Pardon me if I missed this, but why arenít we including some form of
intrusion detection to make security as good as possible? Arnie

 

-----Original Message-----
From: owner-voting-project@afterburner.sonic.net
[mailto:owner-voting-project@afterburner.sonic.net] On Behalf Of Popkin,
Laird (WMG Corp)
Sent: Wednesday, April 21, 2004 2:10 PM
To: 'voting-project@lists.sonic.net'
Subject: RE: [voting-project] Programming languages and trojans

 

There's an advantage in using an interpreted language for the project,
which is that you eliminate the question of whether the binaries that
are distributed match the source code. Admittedly you could argue that
the interpreter itself has been modified to affect elections, but since
the interpreter can be verified (via hash checking) to be unmodified,
someone would have to modify the Python (etc.) interpreter to affect the
OVC software, yet have those changes remain undetected by all other
users of Python, which seems unlikely. We might as well worry about
someone patching the Linux OS to affect elections; not impossible, but
unlikely to avoid detection by all other users of the software.

This all assumes that we use mainstream distributions of the components,
so that there are many users, and that we check hash values of the
software to make sure it's not modified, etc.

And let's keep in mind the alternative that we're trying to beat --
perhaps I'm being too cynical, but I'd say that we don't have to
guarantee absolute security (probably impossible) -- we just have to be
demonstrably better than the black-box DRE's that are being sold. If
we're better, easier, cheaper, more trusted, etc., then we'll eventually
win.

- LP
-----Original Message-----
From: owner-voting-project@afterburner.sonic.net
[HYPERLINK
"mailto:owner-voting-project@afterburner.sonic.net"mailto:owner-voting-p
roject@afterburner.sonic.net]On Behalf Of David
Mertz
Sent: Wednesday, April 21, 2004 1:35 PM
To: voting-project@lists.sonic.net
Subject: [voting-project] Programming languages and trojans

 

On Apr 21, 2004, at 12:58 PM, Douglas W. Jones wrote:
> Generally, there is no way to test for the presence of trojans by any
> form of regression testing.

I'm absolutely in agreement here.

> This is central to my original objections to relying on any language
> that rests on a large interpreter such as Python for anything other
> than a prototype.

Here I don't agree at all. At least not in the context of Doug's other
remarks. There's a lot more code in GCC and libc than there is in the
Python interpreter. Ipso facto, a lot more code in which to hide
trojans. Just because it's compiled doesn't mean something malicious
isn't included in the machine code.

And a Java JVM is WAY, WAY bigger than Python's VM. And JVM's aren't
even Free Software, for the most part. If you actually want small,
look at TCL, or Lua, or maybe small-Eiffel.

As for strong typing... well, Java is still pretty weakly typed as
things go, certainly no more so than Python. If you want STRONG
typing, use Haskell or ML.

Overall, I would have more confidence (security-wise) in an open
program written in Python or Ruby than in any of the other options.
Perl is similarly architecturally, but it's code positively
-encourages- obscure and subtle misbehavior.

If we run EVM software on a version of Python that was released prior
to Aug 2003 (when we launched EVM2003), it's pretty darn hard to
imagine anyone anticipated our project, and inserted a trojan just in
case we developed it (and used a particular set of libraries and
techniques, etc).

Yours, David...

---
A nice word for MS: <IMG SRC="c:\con\con">

---
Incoming mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.659 / Virus Database: 423 - Release Date: 4/15/2004
---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.659 / Virus Database: 423 - Release Date: 4/15/2004
 
==================================================================
= The content of this message, with the exception of any external 
= quotations under fair use, are released to the Public Domain    
==================================================================
Received on Fri Apr 30 23:17:14 2004

This archive was generated by hypermail 2.1.8 : Fri Apr 30 2004 - 23:17:29 CDT