asf-tooling commented on issue #962:
URL:
https://github.com/apache/tooling-trusted-releases/issues/962#issuecomment-4407514262
<!-- gofannon-issue-triage-bot v2 -->
**Automated triage** — analyzed at `main@751c2146`
**Type:** `new_feature` • **Classification:** `actionable` •
**Confidence:** `medium`
**Application domain(s):** `voting`, `release_lifecycle`,
`authentication_authorization`
### Summary
The issue evolved from an original bug report about vote duration validation
into a well-defined new feature request for security releases. @dave2wave
clarified that users ARE allowed to override policy duration (0 or 72-168 are
valid), and the real question is what '0' means. @sbp summarized the agreed
design: security releases are configured at creation time, require PMC
membership for the release manager, restrict voting to private lists only,
allow vote resolution as soon as sufficient votes arrive (no time limit), and
continue counting votes until the release manager resolves. Implementation
requires changes across data models, authorization checks, vote initiation, and
vote resolution logic.
### Where this lives in the code today
#### `atr/shared/voting.py` — `StartVotingForm` (lines 25-53)
_needs modification_
For security releases, vote_duration of 0 should be allowed (it already is
per validation), but the form description and default should adapt based on
whether it's a security release.
```python
class StartVotingForm(form.Form):
email_to: str = form.label("To (mailing list)",
widget=form.Widget.CUSTOM)
email_cc: form.StrList = form.label("CC")
email_bcc: form.StrList = form.label("BCC")
second_round_email_to: str | None = form.label(
"Second round mailing list",
widget=form.Widget.CUSTOM,
default=None,
)
vote_duration: form.Int = form.label(
"Minimum vote duration",
"Minimum number of hours the vote will be open for.",
default=72,
)
subject: str = form.label("Subject", widget=form.Widget.CUSTOM)
subject_template_hash: str = form.label("Subject template hash",
widget=form.Widget.HIDDEN)
body: str = form.label("Body", widget=form.Widget.CUSTOM,
max_length=100_000)
notify_when_finished: form.Bool = form.label(
"Email reminder",
widget=form.Widget.CUSTOM,
default=False,
)
vote_mode: sql.VoteMode = form.label("Vote mode",
widget=form.Widget.HIDDEN)
@pydantic.field_validator("vote_duration")
@classmethod
def validate_vote_duration(cls, field):
util.validate_vote_duration(field)
return field
```
### Where new code would go
- `atr/models/sql.py` — Release model
Needs a boolean field like `is_security_release` on the Release model to
mark releases as security releases at creation time.
- `atr/storage/writers/release.py` — release creation logic
Release creation needs to accept and store the security release flag,
enforcing PMC membership when set.
- `atr/storage/writers/vote.py` — vote.start()
Vote start logic needs to check security release status, enforce private
list restriction, and handle 0-duration votes.
- `atr/db/interaction.py` — release_ready_for_vote
May need additional authorization checks ensuring PMC membership for
security release votes.
### Proposed approach
This is a multi-layered feature that requires: (1) Adding a
`is_security_release` boolean to the Release SQL model, set at creation time.
(2) Enforcing that the release manager is a PMC member (not just a committer)
when creating or voting on a security release — this means checking
`session.is_pmc_member` or equivalent in the authorization layer. (3) Filtering
permitted recipients to private lists only (e.g.,
`private@<committee>.apache.org`) when the release is a security release. (4)
Allowing vote_duration of 0 for security releases, meaning no minimum time —
votes can be resolved once sufficient binding votes are recorded. (5) Updating
vote resolution logic to allow early resolution when enough binding +1 votes
exist, without waiting for a time limit.
The existing code already handles duration=0 gracefully in the task layer
(skipping end_notify scheduling). The main work is in the data model,
authorization enforcement, and recipient filtering. The GET and POST voting
handlers need to be security-release-aware, adapting defaults and validation
accordingly.
### Open questions
- What does the Release model in atr/models/sql.py look like? Need to
confirm where to add the security release flag.
- How is PMC membership checked vs committer status in the current
authorization system? Need to see atr/principal.py or session role checks.
- What constitutes a 'private list' — is it always
`private@<committee>.apache.org` or are there other patterns?
- How does vote resolution currently work? The feature requires allowing
resolution as soon as sufficient votes arrive, which may need changes to
atr/storage/writers/vote.py or atr/tabulate.py.
- Should the security release flag be immutable once set, or can it be
toggled?
- What is the 'proper number of votes' for resolution — is it 3 binding +1
with more +1 than -1 per ASF policy?
- The original issue body mentions atr/storage/writers/policy.py with
_validate_min_hours() — but this was clarified by @dave2wave as working as
designed. Should that file still be reviewed for the security release context?
- Where is util.validate_vote_duration defined and what are its exact rules?
Need to confirm 0 is already accepted.
### Files examined
- `atr/post/voting.py`
- `atr/get/voting.py`
- `atr/shared/voting.py`
- `atr/tasks/vote.py`
---
*Draft from a triage agent. A human reviewer should validate before merging
any change. The agent did not run tests or verify diffs apply.*
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
