On 2015-03-30 17:10, Alan D. Cabrera wrote:
On Mar 30, 2015, at 3:17 AM, Daniel Gruno <humbed...@apache.org> wrote:
On 2015-03-29 20:16, Alan Cabrera wrote:
I was looking at our backend code and noticed that they are in charge of
generating the election hash. In my opinion I think the election hash should be
generated by the callers of the back end and not delegated to the back ends
themselves.
What exactly do you mean by 'callers of the backend'? The person doing the API
call? or the library doing the final call to the DB backend?
Actually, any caller but more specifically the library doing the final call to
the DB backend. The code is duplicated and it’s mixing concerns in the DB
backend code.
I don't see any duplication - but maybe I removed that just don't
remember? (I'm a bit worn out atm).
From what I can see, election.py is the only one doing the hash.
With regards,
Daniel.
It's important that the API has no way of setting/rigging the election hash nor
should anyone but the monitors really know it (and even then, they get a hash
of a hash). The way it is now, in pysteve at least, election.py is in charge of
generating the hash for the election, and I think that's the sane place to put
it.
I’m not sure that election.py is in charge of generating the hash for the
election. It’s duplicated in create_election() of the DB backend code. The DB
backend code should be solely concerned with election persisistance.
In an ideal world, the person setting up an election should not have direct
access to the election server, and should definitely not have access to fiddle
with the election hash.
Agreed, and that separation can only be done when the REST API resides on a
separate protected server. Burying the election hash generation inside the DB
backend code does not provide any security, duplicates code, and mixes concerns
of election generation and management with DB persistence.
Regards,
Alan
