fix(tally): fix shared default ciphertext in tally selection

[mdevolde]

Issue

Fixes#809

Description

This change updates CiphertextTallySelection.ciphertext to use default_factory instead of a shared ElGamalCiphertext instance as a dataclass field default. That ensures each CiphertextTallySelection gets its own ciphertext value rather than sharing the same default object across instances.

The behavior avoids unintended shared state if the default ciphertext is ever mutated in place, and also resolves the dataclass validation error raised by Python 3.11 for mutable defaults.

I ran the tests locally: poetry run pytest tests/unit, poetry run pytest tests/property, poetry run pytest tests/integration (on python 3.9.21, on windows 11). I built the project with poetry build on the same environment.

Testing

Run the relevant tally-related test suites with:

poetry run pytest tests/unit/electionguard
poetry run pytest tests/property/test_tally.py

These validate that CiphertextTallySelection still behaves correctly.

[mdevolde]

@lprichar@jungshadow hey, sorry for tagging you, I just wanted to know if you're still maintaining this repository?

[jungshadow]

Hi @mdevolde! Thanks for the PR and the flag, and sorry I didn't see this earlier. You probably followed that ElectionGuard moved from Microsoft to the Election Technology Initiative, and we're currently trying to determine where our resources should go. The .NET implementation recently received an update and is currently being used by US election tech providers. My heart is always with Python, and I'd personally like to maintain this version, too, but we need both a business need and funding for it. Give me a few days to check with @JDziurlaj on what it would take to set up PR validation here, and I'll see if we can at least merge this in. Thanks again!

[mdevolde]

Hi @jungshadow!
Thank you very much for your response and your honesty! I completely understand your point of view.
Even if only a minimal/occasional maintenance routine can be put in place for this repository, it would likely be beneficial.
It would be a loss if this repository could no longer benefit from community patches and became unusable.

[jungshadow]

@mdevolde, I hear you, and I agree. We had high hopes that this project and its goals would attract significant financial support. Sadly, it hasn't worked out that way, so we're trying to be as strategic as possible with the support we have.

[JDziurlaj]

I apologize for the noise on this PR, I have to close and reopen the PR to force GitHub actions.

[mdevolde]

I apologize for the noise on this PR, I have to close and reopen the PR to force GitHub actions.

No problem !
If you add this in an action workflow, you can trigger it manually:

on:
workflow_dispatch:

[JDziurlaj]

LGTM.

[JDziurlaj]

Once we get a signed CLA, we can merge this change, @mdevolde. Please view my GitHub profile and send me an email, and I'll respond with a Docusign. Thanks!

[mdevolde]

Thank you @JDziurlaj !
It is possible that I reopen some issues/PRs regarding the usability of this lib on the latest versions of python, if I encounter any further issues.
I really appreciate that you’ve taken the trouble to maintain this repository, even if it’s only on an occasional schedule.
Are you planning to bump the package version and upload a new version to PyPI?

[mdevolde]

Update: before bumping lib version and pushing on PyPI, I made a little other PR #813, to ensure that all the dependencies are compatible with our usage.