election software

[Toshio Kuratomi]

Ben Adida wrote:
> Toshio Kuratomi wrote:
>> I'd have to look at the code more, but looking at random files in the
>> base/* directory didn't give me a good feeling.  There were comments at
>> the top of files like, This code was taken from feedparser under License
>> XXX.
> 
> I try to be excessively clear about sources from which I borrow code,
> but the only times I bring them in by source is when the project isn't
> packaged, when I'm using some starting point but then expanding on it,
> or when I need a small piece and can't install the rest because of
> native-code dependencies. Here's an exhaustive list:
> 
<nod> The problem from a distro packager's point of view is that we
don't know how you stack up against the upstream for the module code.
In almost all cases, we'd rather go with upstream for the code since
they have a larger community than just a single app.  That means more
chance of bugs and security issues being detected and fixed upstream
than downstream.

Your list of code includes some files that are simply files from
upstream, some that are legitimately being incorporated into your
codebase, and some that are being taken from upstream and then modified.
 This is a nightmare for packagers as they have to analyze, decide if
there's an active upstream for the code, figure out if they should be
using the upstream system library instead of the copy you have, figure
out if there's any extra bugfixes in your version that they need to get
ported to the system library, figuring out if you're using old, buggy
versions of the library when newer ones have security fixes, and so on.

>> There was other code taken from different projects (github is down
>> so I can't look at what right now) -- it made that directory look like a
>>  packagers nightmare.  If we're not going to use it, I didn't want to
>> deal with analyzing it :-)  If we are, then I (or someone else) will
>> have to.
> 
> So, of course you should analyze the code to your heart's content.
> 
> That said, I just want to point out one important feature: this is a
> cryptographically verifiable voting system, which means the results are
> presented with a mathematic proof of correctness. So, in fact, the only
> part you really *need* to review is the verification program: the
> client/, crypto/ directories.
> 
> I'm not suggesting you ignore the rest of the code, I'm only trying to
> highlight the verifiability of the system.
>
So the analysis mentioned here isn't so much analyzing it for security.
 It's analyzing it to figure out how we're going to package it, if all
the licenses are compatible, etc.  Analyzing the code for use as
Fedora's voting software is a different beast :-)

>> <nod>  I'm not complaining about it, just noting it.  It limits the
>> database backends that can be used to the ones that the app has been
>> ported to rather than letting the ORM manage database portability.  (I
>> love postgres but, as mmcgrath tells me frequently, mysql is much easier
>> to administer which makes him much happier :-)
> 
> Well, I won't get into a DB fight, but... are you trying to package this
> for aptitude-style installation? That's great but it might be a bit
> premature for that.
>
yes. If we run it in Fedora Infrastructure we need to package it for
Fedora.  It's not a 100% hard and fast rule but it's a pretty big thing.
 We want to make sure that the software is suitable for Fedora and we
want to make sure that we're sharing the knowledge of what makes our
infrastructure work with the rest of the world.

> Would you consider running the election at heliosvoting.org and using
> the Python verification programs (which you can and should audit) to
> verify the election? That should make it quite easy for you (and just as
> verifiable.)
> 
Probably not... but not necessarily no :-)  That's probably a board
question and I'm an infrastructure guy instead.  (This is a list where
Board Members take in information, though, so they can make their
preference known :-)

> Of course, installing it yourself is a perfectly fine option (once pgsql
> is supported), just a lot more work and not any real additional
> verifiability.
> 
Understood.

>> My basic aim is figuring out how we'd tie the authentication in the app
>> into our account system.
> 
> 1) I would recommend not tying this to an existing auth system: just use
> election-specific passwords emailed to folks. Simpler and really just as
> good since there is a *public* verification phase where everyone can
> check that the hash of their vote is on the public bulletin board.
> 
We probably would want to tie to the existing auth system.  Currently we
allow people to join groups while elections are in progress and they get
to vote in those elections.  Keeping track of group joining while an
election is in progress and sending out new one-time passwords wouldn't
be the best in this situation.  Also, I'm pretty sure that some of our
users won't like the fact that the passwords travel via email. (We could
encrypt with GPG if we have a key on file or something but that's extra
work that when we'd be happier to put the extra work into getting our
authentication working with the app).

> 2) If you really want to tie it to your existing auth system, you could
> hack the code or use the OAuth-based API where you build a different
> front-end that sends votes to the server via REST calls. I'm working
> with a large university that wants to do just this, so we'll have sample
> code for this approach in a couple of months.
> 
Are you talking about a different front-end to the account system or a
different front-end to the election server?  This is certainly something
we could look into in either case.  We need to find some method of
pushing authorization data from our account system to other web
applications and oauth was something we wanted to look into for that.

>>>>> I ran into tracebacks creating a new election so I'm not
>>>>> sure how it works in practice.
>>> Where, at www.heliosvoting.org? Or running it on your own? The pgsql
>>> version is not working yet. Do you have the full traceback?
>>>
>>> You can report and track the bug at: http://helios.lighthouseapp.com
>>>
>> Yeah, at heliosvoting.org.  I first tried to create an election managed
>> by trustees and got a traceback.  Then I tried to create an election
>> managed by myself and got a traceback. Didn't explore further.  Since I
>> was just evaluating how it stacked up to what we have now, Im afraid I
>> didn't file a bug report.  Sorry.
> 
> No problem. Can't reproduce either of these right now, but let me know
> when you do reproduce them.
> 
Something's wrong with java::

BigInt.APPLET.newBigInteger is not a function
http://www.heliosvoting.org/static/bigint.js
Line 21

I have the gcjwebplugin (using IcedTea) installed and enabled.  If that
doesn't work we'll have problems as that's what ships with Fedora.

>> Hmm..... there's upsides and downsides to this.  We want to have
>> accessibility for voting if possible so a reliance on java and
>> javascript is problematic.  If there's a json or xmlrpc interface, then
>> we could code an alternate front-end.
> 
> Using Java and JavaScript should not preclude accessibility. Java is
> only used for bignum computation, never UI. JavaScript is used to glue
> HTML and Java together. The HTML should be easily customizable to be
> screen-reader friendly or otherwise accessible.
> 
> Now, if you're thinking about a lynx interface, that is indeed a
> problem, but it's a problem that gets at the heart of the features
> offered by Helios: Helios *needs* the browser to be able to do crypto so
> the vote can be sealed encrypted before it leaves the browser.
> 
<nod>  That's what I'm thinking.  Now we haven't had complaints yet that
any of the web sites we have are not accessible this way but there's
only one (useful to packagers only) that is not usable in lynx.  And it
is a goal of ours to have accessible web apps.

Is a command line front end a possibility?  Does your app have a json or
xmlrpc that we could tap into?

In terms of actually using the Helios Voting app for Fedora Elections,
you want to talk with Nigel Jones as he's the coder behind our current
voting app.  I'm just raising issues that we'll have to address if we
choose to switch.

-Toshio

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/fedora-advisory-board/attachments/20081008/1b6d0061/attachment.sig>