election software

[Toshio Kuratomi]

Ben Adida wrote:

> Toshio: I see you're going through the code with a fine-tooth comb...
> very nice. I look forward to more comments. I think you'll see that most
> of your concerns are simply (small) side-effects of the hosted App
> Engine setting.
> 
>>> It makes some bad choices as an open source project but nothing that's
>>> not fixable.  (Keeping local copies of third-party upstream sources
>>> jumps out at me immediately.  Keeping partial local copies of third
>>> party modules and mixing those together and with the developer's own
>>> code makes me shiver).
> 
> The only reason local copies of third-party packages are kept is because
> Google App Engine doesn't have them built in, so they have to be present
> as part of the source tree. If you have the third-party packages
> installed in your Python path, and you're running the pgsql version
> (when it's ready), you can rm -rf those third-party packages.
> 
Cool.  The cherrypy inclusion looked clean like this :-)

> Can you expand on what you mean by "partial" local copies, or by
> "mixing"? I'm pretty sure I'm not mixing any code, it's more like
> bundling because I can't count on the python path at App Engine.
> 
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.  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.

>>> This is written in python with cherrypy as its object dispatcher.  But
>>> it also makes use of django utility functions (django's local copy of
>>> python-simplejson :-(
> 
> Also because of Google App Engine, which has django built in but not the
> standalone version of simplejson. Thus you see me trying to import
> simplejson, and if that fails I try to import the one from django.
> 
The code actually does the reverse of that :-)  Not a big deal, just
need to switch the failure case (and for Fedora, remove simplejson from
django bz#464885).

> Just a couple of lines of code, though, nothing that can't be quickly
> fixed once the dependency is gone :)
> 
>>> It looks like the Google App Engine code is
>>> required at the moment but it's being ported to work with a plain
>>> postgresql backend.  I don't see signs of an ORM being used although the
>>> code is being ported to a home-built db abstraction layer based on the
>>> Google App Engine.
> 
> I'm very dubious of ORM in general, both in terms of performance and
> transparency. I prefer dictionary wrapping of SQL results. The
> home-built db abstraction layer is one that I've worked on for years on
> many projects, and I've only just recently adapted it to Google App Engine.
> 
> Also, the layer is really just a wrapper around DBUtils and psycopg2.
> The heavy lifting is done by those existing libraries. My API just
> exposes a simpler API especially when it comes to transactions and
> connection management.
> 
<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 :-)

>>> I don't see very much information in the app's data model for limiting
>>> who can vote.
> 
> Voters have passwords that are auto-generated on the server side. Only
> voters that are listed for an election are allowed to vote. Is there
> something else you were expecting to see in the data model?
> 
I'm not certain.  github is down right now or I could look at the
various files I was looking at before :-)

My basic aim is figuring out how we'd tie the authentication in the app
into our account system.

>>> 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.


>>> The "Java support required for heliosvoting" popup is disconcerting...
>>> Is that a Google App Engine requirement?
> 
> This is a key feature of Helios, not a Google App Engine requirement.
> 
> Java is used on the client side, in your browser, to perform ballot
> encryption before your ballot even leaves your browser. It is also used
> to generated zero-knowledge proofs that your ballot was correctly created.
> 
> The key idea of Helios is that it implements security and verifiability
> features that go far beyond any other voting system. You get to verify
> that your vote actually counted, and you get a cryptographic proof of
> that result. Again, I want to stress: there is no other web-based voting
> system that provides anywhere close to this level of verifiability today.
> 
> (If JavaScript had a bignum library, I wouldn't be using Java, of course.)
> 
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.

-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://lists.fedoraproject.org/pipermail/advisory-board/attachments/20081008/ad894972/attachment.bin