(tooling-agents) branch main updated: ASVS audit: 13.1.2.md (redacted) [source: apache/steve/v3 @ d0aa7e9]

[as...@apache.org]

This is an automated email from the ASF dual-hosted git repository.

asf-tooling pushed a commit to branch main
in repository https://gitbox.apache.org/repos/asf/tooling-agents.git


The following commit(s) were added to refs/heads/main by this push:
     new 8c506ca  ASVS audit: 13.1.2.md (redacted) [source: apache/steve/v3 @ d0aa7e9]
8c506ca is described below

commit 8c506ca972824da7f6010475b02f1c5a936ac6bb
Author: ASF Tooling Team <ro...@apache.org>
AuthorDate: Tue May 5 22:52:43 2026 +0200

    ASVS audit: 13.1.2.md (redacted) [source: apache/steve/v3 @ d0aa7e9]
---
 ASVS/reports/steve/v3/d0aa7e9/all/13.1.2.md | 159 ++++++++++++++++++++++++++++
 1 file changed, 159 insertions(+)

diff --git a/ASVS/reports/steve/v3/d0aa7e9/all/13.1.2.md b/ASVS/reports/steve/v3/d0aa7e9/all/13.1.2.md
new file mode 100644
index 0000000..81376b8
--- /dev/null
+++ b/ASVS/reports/steve/v3/d0aa7e9/all/13.1.2.md
@@ -0,0 +1,159 @@
+# Security Audit Report: ASVS 13.1.2
+
+## Executive Summary
+
+| Field | Value |
+|-------|-------|
+| **Repository** | apache/steve/v3 |
+| **Audit Date** | May 05, 2026 |
+| **Auditor** | Tooling Agents (bundled-pass mode) |
+| **ASVS Requirement** | ASVS 13.1.2 |
+| **Files Analyzed** | 14 relevant / 49 total |
+| **Files Skipped** | 12 |
+
+**Requirement description:** Verify that for each service the application uses, the documentation defines the maximum number of concurrent connections (e.g., connection pool limits) and how the application behaves when that limit is reached, including any fallback or recovery mechanisms, to prevent denial of service conditions.
+
+### Findings Overview
+
+| Severity | Count |
+|----------|-------|
+| 🔴 Critical | 0 |
+| 🟠 High | 0 |
+| 🟡 Medium | 1 |
+| 🟢 Low | 0 |
+
+---
+
+## ASVS-13.1.2: Connection Pool Limits and Fallback
+
+### Findings for 13.1.2
+
+#### [MEDIUM]
+**Finding ID:** ASVS-1312-MED-001
+
+**Title:** No documentation of concurrent connection limits or fallback mechanisms for any service
+
+**Location:** `v3/ARCHITECTURE.md`, `v3/steve/election.py`, `v3/server/pages.py`
+
+**Description:** The application interacts with multiple services (SQLite, OAuth, SMTP) but there is no documentation defining maximum concurrent connections, connection pool limits, or behavior when those limits are reached.
+
+**Evidence of unmanaged connections:**
+
+1. **Database connections are opened per-operation without pooling:**
+```python
+# v3/steve/election.py, lines 35-37
+@staticmethod
+def open_database(db_fname):
+    return asfpy.db.DB(db_fname, yaml_fname=QUERIES, yaml_section='election')
+```
+
+Each `Election()` instantiation opens a new database connection:
+```python
+# v3/steve/election.py, lines 39-44
+def __init__(self, db_fname, eid, op='Opening'):
+    _LOGGER.debug(f'{op} election ID "{eid}"')
+    self.db = self.open_database(db_fname)
+    self.eid = eid
+```
+
+2. **Web handlers create new Election/PersonDB instances per request:**
+```python
+# v3/server/pages.py, load_election decorator, lines 165-186
+async def loader(eid):
+    try:
+        e = steve.election.Election(DB_FNAME, eid)
+    # ... no connection management
+```
+
+```python
+# v3/server/pages.py, admin_page, line 297
+pdb = steve.persondb.PersonDB.open(DB_FNAME)
+```
+
+3. **ARCHITECTURE.md mentions connections without limits:**
+```
+### Data Layer
+- **Connections**: Database connections are opened per operation or cached
+  in the app context. Uses `sqlite3` with row factories for dict-like access.
+```
+
+No documentation exists for:
+- Maximum concurrent SQLite connections
+- OAuth service connection timeouts/limits
+- SMTP connection pooling or rate limits
+- Fallback behavior if any service becomes unavailable
+
+**Impact:** Under high load or during service outages, the application may exhaust file descriptors, memory, or other resources. Without defined limits and fallback mechanisms, a denial-of-service condition could result from legitimate traffic spikes or upstream service degradation.
+
+**Remediation:** Document for each service:
+- Connection pool size or maximum concurrent connections
+- Queue/backpressure behavior when limits are reached
+- Circuit breaker or fallback patterns
+- Example configuration:
+
+```yaml
+# config.yaml - proposed additions
+database:
+  max_connections: 10
+  connection_timeout_ms: 5000
+  behavior_at_limit: queue  # or reject
+
+oauth:
+  max_concurrent_requests: 5
+  timeout_ms: 10000
+  fallback: deny_login
+
+smtp:
+  max_concurrent_sends: 3
+  retry_on_failure: false
+```
+
+### Security Controls Inventory for 13.1.2
+
+| Control | Location | Coverage |
+|---------|----------|----------|
+| Connection management | `v3/steve/election.py` | None — new connection per operation, no pool limits |
+| Architecture docs | `v3/ARCHITECTURE.md` | None — mentions connections but no limits |
+| Config | `v3/server/config.yaml.example` | None — only port and TLS settings |
+
+### Positive Patterns for 13.1.2
+
+- SQLite is inherently simpler for connection management than networked databases
+- The `delete()` method in `election.py` properly closes the connection after use: `self.db.conn.close()`
+- The application uses Quart (async framework) which can handle concurrent requests without blocking threads on I/O
+
+---
+
+
+
+## Cross-cutting Architecture Observations
+
+1. **Documentation vs. Implementation Gap**: The application has good architectural documentation (`ARCHITECTURE.md`, `schema.md`) covering design intent, but lacks operational documentation required by ASVS Level 2-3 (communication inventories, resource management strategies, secrets rotation schedules).
+
+2. **Single Database Pattern**: The use of SQLite as an embedded database simplifies many backend communication concerns (no network authentication needed, no connection pool management) but makes it impossible to apply traditional service-account or role-based database access controls.
+
+3. **Trust Boundary Ambiguity**: The `TODO.md` file acknowledges multiple unimplemented security controls (`### check authz` placeholders, CSRF placeholder). The system currently relies primarily on the ASF OAuth committer-level authentication as its sole access control boundary, with no fine-grained authorization distinguishing election owners from other committers.
+
+4. **Operational Tooling Without Controls**: CLI scripts (`create-election.py`, `mail-voters.py`) operate with the same privileges as the web server but without any authentication or authorization layer, creating a potential privilege escalation path for anyone with shell access.
+
+5. **Consistent Cryptographic Approach**: The cryptographic design (Argon2 key derivation, separate salts per voter-issue pair, encrypted votes, anti-tamper keys) is well-documented and consistently applied, representing a strength in the security architecture.
+
+---
+
+## Cross-cutting Recommendations
+
+### Immediate (Address within current sprint)
+1. **Create a Communications Inventory document** listing all external services (OAuth, SMTP, LDAP), protocols, authentication methods, and network requirements — satisfies ASVS 13.1.1 at minimal implementation cost
+2. **Document existing secrets** and their criticality in a secrets inventory, even without rotation automation — satisfies ASVS 13.1.4 documentation requirement
+
+### Short-term (1-3 months)
+3. **Add resource management documentation** defining timeouts, connection limits, and failure handling for SQLite, OAuth, and SMTP — satisfies ASVS 13.1.2 and 13.1.3
+4. **Implement read-only database connections** for components that only need read access (mail script, voter-facing queries) — improves ASVS 13.2.2 compliance
+5. **Implement TLS certificate rotation procedures** and document the rotation schedule
+
+### Long-term (3-6 months)
+6. **Evaluate migration from SQLite** to a database that supports role-based access control if the application scales beyond single-server deployment — would fully satisfy ASVS 13.2.1 and 13.2.2
+7. **Implement connection lifecycle management** with explicit open/close patterns (context managers) for all database access paths to prevent resource leaks
+8. **Add circuit breaker patterns** for OAuth and SMTP communication with documented fallback behavior
+9. **Implement proper CSRF tokens and session-based secrets** with defined rotation (currently placeholder) — prerequisite for ASVS 13.1.4 compliance on session secrets
+        
\ No newline at end of file


---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@tooling.apache.org
For additional commands, e-mail: commits-help@tooling.apache.org