[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: The Debian vote taking machinery (Very Long)

On Mon, 25 Feb 2002, Manoj Srivastava wrote:

> 	In the current method, an incoming vote is fed to a script
>  that, on the fly, checks the signature on the message, queries the
>  LDAP for canonical information, generates a response, extracts the
>  vote information, and writes it out to a plain text database. 

Aside from the last bit, this is the script I constructed for Darren
specifically for this purpose. It is essentially the same script that is
used by the LDAP gateway and does a large wack of stuff to ensure
validity of the PGP signed mails. I do not recommend replacing it, it took
a very long time to get all the MIME crap right (stupid mailers not
following standards).

I think you actually have some of the details wrong, the front end python
script actually talks to a perl script that does the back end processing
(this is where the locking problems you mention would be hiding)
Further, I think you are likely wrong about the locking. The gpgwrapper
script does fcntl locking and will only run a single instance of it's
child script. This is a bit hard to see since it is a side effect of they
way it uses its internal replay cache..

Currently all mail is spooled into a standard mail spool immediately on
recipit by Exim, this is 100% correct and guarenteed. Exim also
automatically BCC's to the vote machinery, so the voter gets immediate
feedback on the vote. 

The vote machinery uses it's return code in the same way procmail does to
use exim as a queueing agent, this ensures no mail is lost, everything is
100% certain to get a response or a bounce. 

Frankly, I do not think you will find any flaws (aside from asthetic ones,
the bounce failure responses are ugly as sin, but correct..) in the
current gpgwrapper script. I do not think you will have time to complete
and test a new vote infrastructure in time (we did this last time, it


Reply to: