feat: add support for Pushover notification provider
- Updated the list of supported notification provider types to include 'pushover'. - Enhanced the notifications API tests to validate Pushover integration. - Modified the notifications form to include fields specific to Pushover, such as API Token and User Key. - Implemented CRUD operations for Pushover providers in the settings. - Added end-to-end tests for Pushover provider functionality, including form rendering, payload validation, and security checks. - Updated translations to include Pushover-specific labels and placeholders.
This commit is contained in:
GitHub Actions
@@ -18,6 +18,7 @@ Notifications can be triggered by various events:
|
||||
| **Discord** | ✅ Yes | ✅ Webhooks | ✅ Embeds |
|
||||
| **Slack** | ✅ Yes | ✅ Webhooks | ✅ Native Formatting |
|
||||
| **Gotify** | ✅ Yes | ✅ HTTP API | ✅ Priority + Extras |
|
||||
| **Pushover** | ✅ Yes | ✅ HTTP API | ✅ Priority + Sound |
|
||||
| **Custom Webhook** | ✅ Yes | ✅ HTTP API | ✅ Template-Controlled |
|
||||
| **Email** | ❌ No | ✅ SMTP | ✅ HTML Branded Templates |
|
||||
|
||||
@@ -214,6 +215,51 @@ Slack notifications send messages to a channel using an Incoming Webhook URL.
|
||||
- Use `•` for bullet points
|
||||
- Slack automatically linkifies URLs
|
||||
|
||||
### Pushover
|
||||
|
||||
Pushover delivers push notifications directly to your iOS, Android, or desktop devices.
|
||||
|
||||
**Setup:**
|
||||
|
||||
1. Create an account at [pushover.net](https://pushover.net) and install the Pushover app on your device
|
||||
2. From your Pushover dashboard, copy your **User Key**
|
||||
3. Create a new **Application/API Token** for Charon
|
||||
4. In Charon, go to **Settings** → **Notifications** and click **"Add Provider"**
|
||||
5. Select **Pushover** as the service type
|
||||
6. Enter your **Application API Token** in the token field
|
||||
7. Enter your **User Key** in the User Key field
|
||||
8. Configure notification triggers and save
|
||||
|
||||
> **Security:** Your Application API Token is stored securely and is never exposed in API responses.
|
||||
|
||||
#### Basic Message
|
||||
|
||||
```json
|
||||
{
|
||||
"title": "{{.Title}}",
|
||||
"message": "{{.Message}}"
|
||||
}
|
||||
```
|
||||
|
||||
#### Message with Priority
|
||||
|
||||
```json
|
||||
{
|
||||
"title": "{{.Title}}",
|
||||
"message": "{{.Message}}",
|
||||
"priority": 1
|
||||
}
|
||||
```
|
||||
|
||||
**Pushover priority levels:**
|
||||
|
||||
- `-2` - Lowest (no sound or vibration)
|
||||
- `-1` - Low (quiet)
|
||||
- `0` - Normal (default)
|
||||
- `1` - High (bypass quiet hours)
|
||||
|
||||
> **Note:** Emergency priority (`2`) is not supported and will be rejected with a clear error.
|
||||
|
||||
## Planned Provider Expansion
|
||||
|
||||
Additional providers (for example Telegram) are planned for later staged
|
||||
|
||||
+719
-232
File diff suppressed because it is too large
Load Diff
@@ -0,0 +1,309 @@
|
||||
# Fix Plan: 6 HIGH CVEs in node:24.14.0-alpine frontend-builder Stage
|
||||
|
||||
**Status:** Active
|
||||
**Created:** 2026-03-16
|
||||
**Branch:** `fix/node-alpine-cve-remediation`
|
||||
**Scope:** `Dockerfile` — `frontend-builder` stage only
|
||||
**Previous Plan:** Backed up to `docs/plans/current_spec.md.bak`
|
||||
|
||||
---
|
||||
|
||||
## 1. Introduction
|
||||
|
||||
The `frontend-builder` stage in the multi-stage `Dockerfile` is pinned to:
|
||||
|
||||
```dockerfile
|
||||
# renovate: datasource=docker depName=node
|
||||
FROM --platform=$BUILDPLATFORM node:24.14.0-alpine@sha256:7fddd9ddeae8196abf4a3ef2de34e11f7b1a722119f91f28ddf1e99dcafdf114 AS frontend-builder
|
||||
```
|
||||
|
||||
Docker Scout (via Docker Hub) and Grype/Trivy scans report **6 HIGH-severity CVEs** in this image. Although the `frontend-builder` stage is build-time only and does not appear in the final runtime image, these CVEs are still relevant for **supply chain security**: CI scans, SBOM attestations, and SLSA provenance all inspect intermediate build stages. Failing to address them causes CI gates to fail and weakens the supply chain posture.
|
||||
|
||||
---
|
||||
|
||||
## 2. Research Findings
|
||||
|
||||
### 2.1 Current Image
|
||||
|
||||
| Field | Value |
|
||||
|---|---|
|
||||
| Tag | `node:24.14.0-alpine` |
|
||||
| Multi-arch index digest (used in FROM) | `sha256:7fddd9ddeae8196abf4a3ef2de34e11f7b1a722119f91f28ddf1e99dcafdf114` |
|
||||
| amd64 platform-specific manifest digest | `sha256:e9445c64ace1a9b5cdc60fc98dd82d1e5142985d902f41c2407e8fffe49d46a3` |
|
||||
| arm64/v8 platform-specific manifest digest | `sha256:0e0d39e04fdf3dc5f450a07922573bac666d28920df2df3f3b1540b0aba7ab98` |
|
||||
| Base Alpine version | Alpine 3.23 |
|
||||
| Compressed size (amd64) | 53.63 MB |
|
||||
| Last pushed on Docker Hub | 2026-02-26 (19 days before research date) |
|
||||
|
||||
### 2.2 Docker Hub Floating Tag Alignment
|
||||
|
||||
`docker manifest inspect node:24-alpine` confirmed on 2026-03-16:
|
||||
|
||||
- amd64: `sha256:e9445c64ace1a9b5cdc60fc98dd82d1e5142985d902f41c2407e8fffe49d46a3`
|
||||
- arm64/v8: `sha256:0e0d39e04fdf3dc5f450a07922573bac666d28920df2df3f3b1540b0aba7ab98`
|
||||
- s390x: `sha256:965b4135b1067dca4b1aff58675c9b9a1f028d57e30c2e0d39bcd9863605ad62`
|
||||
|
||||
The Docker Hub layers page for the amd64 manifest confirms **INDEX DIGEST: `sha256:7fddd9ddeae8196abf4a3ef2de34e11f7b1a722119f91f28ddf1e99dcafdf114`** — exactly matching the digest pinned in the Dockerfile.
|
||||
|
||||
**`node:24-alpine`, `node:24-alpine3.23`, and `node:24.14.0-alpine` all resolve to the identical multi-arch index digest.** There is no newer `node:24.x.y-alpine` image on Docker Hub as of 2026-03-16.
|
||||
|
||||
### 2.3 CVE Summary
|
||||
|
||||
Docker Scout scan of `node:24-alpine` amd64 manifest `sha256:e9445c64ace1...`:
|
||||
|
||||
| CVE ID | CVSS | Severity | Package manager | Package | Version |
|
||||
|---|---|---|---|---|---|
|
||||
| CVE-2026-26996 | 8.7 | **HIGH** | npm | minimatch | 10.1.2 |
|
||||
| CVE-2026-29786 | 8.2 | **HIGH** | npm | tar | 7.5.7 |
|
||||
| CVE-2026-31802 | 8.2 | **HIGH** | npm | tar | 7.5.7 |
|
||||
| CVE-2026-27904 | 7.5 | **HIGH** | npm | minimatch | 10.1.2 |
|
||||
| CVE-2026-27903 | 7.5 | **HIGH** | npm | minimatch | 10.1.2 |
|
||||
| CVE-2026-26960 | 7.1 | **HIGH** | npm | tar | 7.5.7 |
|
||||
| CVE-2025-60876 | 6.5 | MEDIUM | apk | alpine/busybox | 1.37.0-r30 |
|
||||
| CVE-2026-22184 | 4.6 | MEDIUM | apk | alpine/zlib | 1.3.1-r2 |
|
||||
| CVE-2026-27171 | 2.9 | LOW | apk | alpine/zlib | 1.3.1-r2 |
|
||||
|
||||
**Total: 0 Critical, 6 High, 2 Medium, 1 Low**
|
||||
**Docker Scout fixability as of 2026-03-16: 0 Fixable** (no patched versions yet available in Alpine apk repositories or npm registry)
|
||||
|
||||
### 2.4 CVE Location Analysis
|
||||
|
||||
All **6 HIGH** CVEs are in **npm's own internally-bundled packages**, not in the frontend project's `node_modules`. These packages live inside the image at:
|
||||
|
||||
```
|
||||
/usr/local/lib/node_modules/npm/node_modules/minimatch/ ← CVE-2026-26996, CVE-2026-27904, CVE-2026-27903
|
||||
/usr/local/lib/node_modules/npm/node_modules/tar/ ← CVE-2026-29786, CVE-2026-31802, CVE-2026-26960
|
||||
```
|
||||
|
||||
`minimatch` is used by the npm CLI for glob pattern matching. `tar` is used by npm for `.tgz` tarball extraction during `npm install`/`npm ci`. These are NOT declared in `frontend/package.json`; they are shipped inside the npm CLI binary itself.
|
||||
|
||||
The **2 MEDIUM + 1 LOW** CVEs are in Alpine OS packages managed by apk:
|
||||
- `busybox@1.37.0-r30`: CVE-2025-60876
|
||||
- `zlib@1.3.1-r2`: CVE-2026-22184, CVE-2026-27171
|
||||
|
||||
### 2.5 `apk upgrade` Effectiveness
|
||||
|
||||
`apk upgrade --no-cache` operates exclusively on Alpine apk-managed packages. It has no effect on files under `/usr/local/lib/node_modules/`.
|
||||
|
||||
| CVE set | Fixed by `apk upgrade`? |
|
||||
|---|---|
|
||||
| 6 HIGH (npm/minimatch, npm/tar) | **No** — these are npm-managed, not apk-managed |
|
||||
| 2 MEDIUM + 1 LOW (apk/busybox, apk/zlib) | **Yes, once Alpine maintainers publish patches** — currently 0 fixable per Docker Scout, but the `apk upgrade` step will apply patches automatically when they land |
|
||||
|
||||
### 2.6 Renovate Automation
|
||||
|
||||
The Dockerfile already carries the correct Renovate comment on the line immediately before the FROM:
|
||||
|
||||
```dockerfile
|
||||
# renovate: datasource=docker depName=node
|
||||
FROM --platform=$BUILDPLATFORM node:24.14.0-alpine@sha256:7fddd9... AS frontend-builder
|
||||
```
|
||||
|
||||
When the Node.js project publishes `node:24.15.0-alpine` (or later) to Docker Hub, Renovate will automatically propose a PR updating the version tag (`24.14.0` → next) and the `@sha256:` digest to the new multi-arch index. That Renovate PR is the **definitive fix path** because the new release will ship npm bundling patched `minimatch` and `tar`.
|
||||
|
||||
### 2.7 Risk Assessment
|
||||
|
||||
| Risk factor | Assessment |
|
||||
|---|---|
|
||||
| Appears in final runtime image | **No** — only the compiled `dist/` output is `COPY`-ed to the final stage |
|
||||
| Exploitable at runtime | **No** — `npm`, `minimatch`, and `tar` are not present in the final image |
|
||||
| Exploitable during build | Theoretical (supply chain attack on the build worker) |
|
||||
| CI scan failures | **Yes** — Grype/Trivy flag build stages; this is the main driver for the fix |
|
||||
| SBOM/SLSA impact | **Yes** — SBOM includes build-stage packages; HIGH CVEs degrade attestation quality |
|
||||
|
||||
---
|
||||
|
||||
## 3. Technical Specification
|
||||
|
||||
### 3.1 FROM Line — No Change (No Newer Image Available)
|
||||
|
||||
Since `node:24-alpine` and `node:24.14.0-alpine` resolve to the **same** multi-arch index digest (`sha256:7fddd9...`), there is no newer pinned image to upgrade to. **The FROM line does not change.** Renovate handles future image bumps autonomously.
|
||||
|
||||
### 3.2 Changes to `frontend-builder` Stage
|
||||
|
||||
**Single file changed:** `Dockerfile`
|
||||
|
||||
**Locations:** Two changes in `Dockerfile`.
|
||||
|
||||
**Change A — Top-level ARG (Pinned Toolchain Versions block):**
|
||||
|
||||
Add after the existing `ARG XNET_VERSION` line in the `# ---- Pinned Toolchain Versions ----` section:
|
||||
|
||||
```diff
|
||||
# renovate: datasource=go depName=golang.org/x/net
|
||||
ARG XNET_VERSION=0.51.0
|
||||
+
|
||||
+# renovate: datasource=npm depName=npm
|
||||
+ARG NPM_VERSION=11.11.1
|
||||
```
|
||||
|
||||
**Change B — `frontend-builder` stage (before `RUN npm ci`):**
|
||||
|
||||
```diff
|
||||
# Vite 8: Rolldown native bindings auto-resolved per platform via optionalDependencies
|
||||
|
||||
+# Upgrade npm to replace its bundled minimatch/tar with patched versions
|
||||
+# Addresses: CVE-2026-26996, CVE-2026-27903, CVE-2026-27904 (npm/minimatch)
|
||||
+# CVE-2026-26960, CVE-2026-29786, CVE-2026-31802 (npm/tar)
|
||||
+# Run apk upgrade for Alpine package CVEs (busybox, zlib) once patches land
|
||||
+# hadolint ignore=DL3017
|
||||
+RUN apk upgrade --no-cache && \
|
||||
+ npm install -g npm@${NPM_VERSION} --no-fund --no-audit && \
|
||||
+ npm cache clean --force
|
||||
+
|
||||
RUN npm ci
|
||||
```
|
||||
|
||||
### 3.3 Step-by-Step Rationale
|
||||
|
||||
| Added command | Rationale |
|
||||
|---|---|
|
||||
| `apk upgrade --no-cache` | Applies any Alpine repo patches for busybox (CVE-2025-60876) and zlib (CVE-2026-22184, CVE-2026-27171) without changing the base image pin. Currently 0 fixable per Docker Scout, but will take effect automatically once Alpine maintainers ship packages. |
|
||||
| `npm install -g npm@${NPM_VERSION} --no-fund --no-audit` | Replaces `/usr/local/lib/node_modules/npm/` (and its bundled `minimatch` + `tar`) with the pinned npm release from the npm registry. `NPM_VERSION` is declared as `11.11.1` in the top-level Pinned Toolchain Versions ARG block and tracked by Renovate's npm datasource manager. `--no-fund` and `--no-audit` suppress log noise during build. If a patched npm has been published since the node image was created, this eliminates the 6 HIGH CVEs. |
|
||||
| `npm cache clean --force` | Clears npm's cache after the global upgrade to prevent stale entries interfering with the subsequent `npm ci`. |
|
||||
|
||||
### 3.4 Caveats
|
||||
|
||||
**"0 Fixable" status:** Docker Scout reports zero fixable CVEs across all 9 at research time (2026-03-16), meaning patched npm packages are not yet in the registry. The `npm install -g npm@${NPM_VERSION}` step is **defensive** — it will self-apply patches as soon as the npm team publishes a release bundling fixed dependencies. When that release is published, Renovate will propose a bump to `NPM_VERSION` which is all that is needed.
|
||||
|
||||
**Definitive fix:** A new `node:24.x.y-alpine` image from the Node.js release team (bundling a fixed npm version) is the complete resolution. Renovate auto-detects and proposes this update.
|
||||
|
||||
**`npm ci` behavior:** `npm ci` installs project dependencies from `frontend/package-lock.json` and is unaffected by upgrading the global npm executable. The frontend project's own `node_modules` are separate from npm's internal bundled packages.
|
||||
|
||||
**npm pinning:** `npm@latest` has been replaced with a top-level `ARG NPM_VERSION=11.11.1` tracked by a Renovate npm datasource comment. The ARG is declared in the Pinned Toolchain Versions block alongside `GO_VERSION`, `XNET_VERSION`, etc. Renovate auto-proposes version bumps when a newer npm release is published. The implemented pattern:
|
||||
|
||||
```dockerfile
|
||||
# renovate: datasource=npm depName=npm
|
||||
ARG NPM_VERSION=11.11.1
|
||||
# hadolint ignore=DL3017
|
||||
RUN apk upgrade --no-cache && \
|
||||
npm install -g npm@${NPM_VERSION} --no-fund --no-audit && \
|
||||
npm cache clean --force
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 4. Implementation Plan
|
||||
|
||||
### Phase 1: Playwright Tests
|
||||
|
||||
No new Playwright tests are required. The change is entirely in the Docker build process, not in application behavior. The E2E suite exercises the running application and does not validate build-stage CVEs.
|
||||
|
||||
### Phase 2: Dockerfile Change
|
||||
|
||||
1. Open `Dockerfile`.
|
||||
2. In the `# ---- Pinned Toolchain Versions ----` section (approximately line 27), locate `ARG XNET_VERSION` and insert the `NPM_VERSION` ARG immediately after it, as specified in §3.2 Change A.
|
||||
3. Locate the `# ---- Frontend Builder ----` comment block (approximately line 88).
|
||||
4. Find the line `# Vite 8: Rolldown native bindings auto-resolved per platform via optionalDependencies`.
|
||||
5. After that line, insert the new RUN block exactly as specified in §3.2 Change B.
|
||||
6. Leave all other lines in the `frontend-builder` stage unchanged.
|
||||
|
||||
### Phase 3: Build Verification
|
||||
|
||||
```bash
|
||||
# Build frontend-builder stage only (fast, ~2 min)
|
||||
docker build --target frontend-builder -t charon-frontend-builder-test .
|
||||
|
||||
# Confirm npm was upgraded (version should be newer than shipped with node:24.14.0-alpine)
|
||||
docker run --rm charon-frontend-builder-test npm --version
|
||||
|
||||
# Grype scan of the built stage
|
||||
grype charon-frontend-builder-test --fail-on high
|
||||
|
||||
# Trivy scan
|
||||
trivy image --severity HIGH,CRITICAL --exit-code 1 charon-frontend-builder-test
|
||||
```
|
||||
|
||||
If patched npm packages are in the registry, Grype and Trivy will report 0 HIGH CVEs for npm packages. If patches are not yet published, both scanners will still report the 6 HIGH CVEs (the `npm@${NPM_VERSION}` step installs `11.11.1`; once the npm team ships a patched release, Renovate bumps `NPM_VERSION` to pick it up).
|
||||
|
||||
### Phase 4: Full Image Build
|
||||
|
||||
```bash
|
||||
docker buildx build --platform linux/amd64,linux/arm64 -t charon:test .
|
||||
```
|
||||
|
||||
Confirm the final runtime image does not inherit the build-stage CVEs:
|
||||
|
||||
```bash
|
||||
docker scout cves charon:test
|
||||
```
|
||||
|
||||
### Phase 5: Monitor Renovate
|
||||
|
||||
No action required. Renovate monitors `node` on Docker Hub via the existing `# renovate: datasource=docker depName=node` comment. When `node:24.15.0-alpine` lands, Renovate opens a PR.
|
||||
|
||||
---
|
||||
|
||||
## 5. Commit Slicing Strategy
|
||||
|
||||
**Decision: Single PR.**
|
||||
|
||||
The entire change is one file (`Dockerfile`), one stage, three lines added. There are no application code changes, no schema changes, no test changes. A single commit and single PR is appropriate.
|
||||
|
||||
### PR-1 — `fix: upgrade npm and apk in frontend-builder to mitigate CVEs`
|
||||
|
||||
| Field | Value |
|
||||
|---|---|
|
||||
| Branch | `fix/node-alpine-cve-remediation` |
|
||||
| Files changed | `Dockerfile` (1 file, ~4 lines added) |
|
||||
| Dependencies | None |
|
||||
| Rollback | `git revert HEAD` on the merge commit |
|
||||
|
||||
**Suggested commit message:**
|
||||
|
||||
```
|
||||
fix: upgrade npm and apk in frontend-builder to mitigate node CVEs
|
||||
|
||||
The node:24.14.0-alpine image used in the frontend-builder stage
|
||||
carries 6 HIGH-severity CVEs in npm's internally-bundled packages:
|
||||
|
||||
minimatch@10.1.2: CVE-2026-26996 (8.7), CVE-2026-27904 (7.5),
|
||||
CVE-2026-27903 (7.5)
|
||||
tar@7.5.7: CVE-2026-29786 (8.2), CVE-2026-31802 (8.2),
|
||||
CVE-2026-26960 (7.1)
|
||||
|
||||
Plus 2 medium and 1 low Alpine CVEs in busybox and zlib.
|
||||
|
||||
No newer node:24.x-alpine image exists on Docker Hub as of 2026-03-16.
|
||||
node:24-alpine resolves to the same multi-arch index digest as the
|
||||
pinned 24.14.0-alpine tag. Renovate will auto-update the FROM line
|
||||
when node:24.15.0-alpine is published.
|
||||
|
||||
Add a pre-npm-ci RUN step in frontend-builder to:
|
||||
- Run `apk upgrade --no-cache` to pick up Alpine package patches for
|
||||
busybox/zlib as soon as they land in the Alpine repos
|
||||
- Run `npm install -g npm@${NPM_VERSION}` (pinned to `11.11.1`,
|
||||
Renovate-tracked via npm datasource) to replace npm's bundled
|
||||
minimatch and tar with patched versions once npm publishes a fix;
|
||||
Renovate auto-proposes NPM_VERSION bumps when newer releases land
|
||||
|
||||
The frontend-builder stage does not appear in the final runtime image
|
||||
so runtime risk is zero; this change targets supply chain security.
|
||||
```
|
||||
|
||||
**Validation gate:** Docker build exits 0; Grype/Trivy scans of the `frontend-builder` target report 0 HIGH CVEs for npm packages (contingent on npm publishing patched releases).
|
||||
|
||||
---
|
||||
|
||||
## 6. Acceptance Criteria
|
||||
|
||||
| # | Criterion | How to verify |
|
||||
|---|---|---|
|
||||
| 1 | Docker build succeeds for `linux/amd64` and `linux/arm64` | `docker buildx build --platform linux/amd64,linux/arm64 --target frontend-builder .` exits 0 |
|
||||
| 2 | No new CVEs introduced | Grype scan of the new build shows no CVEs not already present in the baseline |
|
||||
| 3 | `apk upgrade` runs without error | Build log shows apk output without error exit |
|
||||
| 4 | npm version is upgraded | `docker run --rm charon-frontend-builder-test npm --version` shows a version newer than what shipped with node:24.14.0-alpine |
|
||||
| 5 | `npm ci` still succeeds | Build log shows successful `npm ci` after the upgrade step |
|
||||
| 6 | Final runtime image is unaffected | `docker scout cves charon:latest` shows no increase in CVE count vs pre-change baseline |
|
||||
| 7 | Renovate comment preserved | `# renovate: datasource=docker depName=node` remains on the line immediately before the `FROM` |
|
||||
| 8 | Diagnostic shows 0 HIGH npm CVEs | Grype/Trivy scan of `frontend-builder` target exits 0 with `--fail-on high` once npm publishes patched minimatch/tar |
|
||||
|
||||
---
|
||||
|
||||
## 7. Open Questions / Future Work
|
||||
|
||||
1. **When will `node:24.15.0-alpine` be released?** Node.js 24.x follows a roughly bi-weekly release cadence. Monitor https://github.com/nodejs/node/releases. Renovate handles the FROM update automatically once the image is on Docker Hub.
|
||||
|
||||
2. ~~**Pin npm version?**~~ Resolved. `npm@latest` has been replaced with a pinned `ARG NPM_VERSION=11.11.1` in the Pinned Toolchain Versions block, tracked by Renovate's npm datasource manager. No follow-up PR is required.
|
||||
|
||||
3. **Should `node:24-alpine3.22` be evaluated?** Switching Alpine base versions to 3.22 would produce a different CVE profile but is inconsistent with the final runtime stage already using `alpine:3.23.3`. Not recommended.
|
||||
@@ -0,0 +1,368 @@
|
||||
# QA & Security Audit Report — Pushover Notification Provider
|
||||
|
||||
**Date:** 2026-03-16
|
||||
**Scope:** Pushover notification provider full-stack implementation
|
||||
**Auditor:** QA/Security Review
|
||||
**Verdict:** ✅ PASS with one test fix applied (see FE-001 below)
|
||||
|
||||
---
|
||||
|
||||
## 1. Scope of Changes Reviewed
|
||||
|
||||
| Area | Files |
|
||||
|------|-------|
|
||||
| Backend – feature flags | `backend/internal/notifications/feature_flags.go` |
|
||||
| Backend – router | `backend/internal/notifications/router.go` |
|
||||
| Backend – notification service | `backend/internal/services/notification_service.go` |
|
||||
| Backend – enhanced security service | `backend/internal/services/enhanced_security_notification_service.go` |
|
||||
| Backend – handler (CRUD + Test guards) | `backend/internal/api/handlers/notification_provider_handler.go` |
|
||||
| Backend – unit tests (~10 new test cases) | `backend/internal/services/notification_service_test.go` |
|
||||
| Frontend – form fields | `frontend/src/pages/Notifications.tsx` |
|
||||
| Frontend – supported types | `frontend/src/api/notifications.ts` |
|
||||
| Frontend – i18n | `frontend/src/locales/en/translation.json` |
|
||||
| Frontend – unit tests | `frontend/src/pages/__tests__/Notifications.test.tsx` |
|
||||
| Model | `backend/internal/models/notification_provider.go` |
|
||||
|
||||
---
|
||||
|
||||
## 2. Required Checks — Results
|
||||
|
||||
### 2.1 Backend Compilation
|
||||
|
||||
```
|
||||
cd /projects/Charon/backend && go build ./...
|
||||
```
|
||||
|
||||
**Result: ✅ PASS** — Zero compilation errors across all packages.
|
||||
|
||||
---
|
||||
|
||||
### 2.2 Backend Unit Tests
|
||||
|
||||
```
|
||||
cd /projects/Charon/backend && go test ./...
|
||||
```
|
||||
|
||||
**Result: ✅ PASS** — All 33 packages pass with no failures.
|
||||
|
||||
| Package | Status |
|
||||
|---------|--------|
|
||||
| `internal/api/handlers` | ok (66.1s) |
|
||||
| `internal/services` | ok (75.4s) |
|
||||
| `internal/notifications` | ok (cached) |
|
||||
| All other packages | ok |
|
||||
|
||||
Pushover-specific tests (10 cases, all PASS):
|
||||
|
||||
| Test | Result |
|
||||
|------|--------|
|
||||
| `TestPushoverDispatch_Success` | PASS |
|
||||
| `TestPushoverDispatch_MissingToken` | PASS |
|
||||
| `TestPushoverDispatch_MissingUserKey` | PASS |
|
||||
| `TestPushoverDispatch_MessageFieldRequired` | PASS |
|
||||
| `TestPushoverDispatch_EmergencyPriorityRejected` | PASS |
|
||||
| `TestPushoverDispatch_PayloadInjection` | PASS |
|
||||
| `TestPushoverDispatch_FeatureFlagDisabled` | PASS |
|
||||
| `TestPushoverDispatch_SSRFValidation` | PASS |
|
||||
| `TestIsDispatchEnabled_PushoverDefaultTrue` | PASS |
|
||||
| `TestIsDispatchEnabled_PushoverDisabledByFlag` | PASS |
|
||||
|
||||
---
|
||||
|
||||
### 2.3 Backend Linting
|
||||
|
||||
```
|
||||
cd /projects/Charon && make lint-fast
|
||||
```
|
||||
|
||||
**Result: ✅ PASS** — `0 issues.` (staticcheck, govet, errcheck, ineffassign, unused)
|
||||
|
||||
---
|
||||
|
||||
### 2.4 Frontend TypeScript Check
|
||||
|
||||
```
|
||||
cd /projects/Charon/frontend && npx tsc --noEmit
|
||||
```
|
||||
|
||||
**Result: ✅ PASS** — No TypeScript errors.
|
||||
|
||||
---
|
||||
|
||||
### 2.5 Frontend Unit Tests
|
||||
|
||||
```
|
||||
cd /projects/Charon/frontend && npx vitest run
|
||||
```
|
||||
|
||||
**Result: ✅ PASS (after fix applied — see FE-001)**
|
||||
|
||||
| Test File | Tests | Status |
|
||||
|-----------|-------|--------|
|
||||
| `SecurityNotificationSettingsModal.test.tsx` | 4 | ✅ PASS |
|
||||
| `Notifications.test.tsx` | 34 | ✅ PASS |
|
||||
| `notifications.test.ts` (API layer) | 4 | ✅ PASS |
|
||||
|
||||
Pushover-specific frontend tests confirmed in `Notifications.test.tsx`:
|
||||
- `renders pushover form with API Token field and User Key placeholder` — PASS
|
||||
- Provider type select includes `'pushover'` in options array — PASS
|
||||
|
||||
---
|
||||
|
||||
### 2.6 Pre-commit / Lefthook Hooks
|
||||
|
||||
**Result: ⚠️ N/A** — The project uses Lefthook (`lefthook.yml`), not pre-commit native. No `.pre-commit-config.yaml` is present. Running the `pre-commit` binary directly raises `InvalidConfigError: .pre-commit-config.yaml is not a file`. Code hygiene was verified manually in changed files; no whitespace or formatting issues were found.
|
||||
|
||||
---
|
||||
|
||||
### 2.7 Trivy Filesystem Security Scan
|
||||
|
||||
```
|
||||
cd /projects/Charon && .github/skills/scripts/skill-runner.sh security-scan-trivy
|
||||
```
|
||||
|
||||
**Result: ✅ PASS** — No vulnerabilities or secrets detected.
|
||||
|
||||
```
|
||||
Report Summary
|
||||
┌────────────────────────────────┬───────┬─────────────────┬─────────┐
|
||||
│ Target │ Type │ Vulnerabilities │ Secrets │
|
||||
├────────────────────────────────┼───────┼─────────────────┼─────────┤
|
||||
│ backend/go.mod │ gomod │ 0 │ - │
|
||||
├────────────────────────────────┼───────┼─────────────────┼─────────┤
|
||||
│ frontend/package-lock.json │ npm │ 0 │ - │
|
||||
├────────────────────────────────┼───────┼─────────────────┼─────────┤
|
||||
│ package-lock.json │ npm │ 0 │ - │
|
||||
├────────────────────────────────┼───────┼─────────────────┼─────────┤
|
||||
│ playwright/.auth/user.json │ text │ - │ 0 │
|
||||
└────────────────────────────────┴───────┴─────────────────┴─────────┘
|
||||
[SUCCESS] Trivy scan completed - no issues found
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### 2.8 Regression — Services Package
|
||||
|
||||
```
|
||||
cd /projects/Charon/backend && go test ./internal/services/... -v 2>&1 | grep -E "^(--- PASS|--- FAIL|FAIL|ok)"
|
||||
```
|
||||
|
||||
**Result: ✅ PASS** — All existing service tests continue to pass; no regressions introduced.
|
||||
|
||||
---
|
||||
|
||||
### 2.9 Regression — Handlers Package
|
||||
|
||||
```
|
||||
cd /projects/Charon/backend && go test ./internal/api/handlers/... -v 2>&1 | grep -E "^(--- PASS|--- FAIL|FAIL|ok)"
|
||||
```
|
||||
|
||||
**Result: ✅ PASS** — All existing handler tests continue to pass; no regressions introduced.
|
||||
|
||||
---
|
||||
|
||||
## 3. Security Code Review
|
||||
|
||||
### 3.1 Token JSON Serialization (`json:"-"`)
|
||||
|
||||
**Model field** (`backend/internal/models/notification_provider.go`):
|
||||
```go
|
||||
Token string `json:"-"` // Auth token for providers — never exposed in API
|
||||
```
|
||||
|
||||
**Finding: ✅ SECURE**
|
||||
|
||||
The `Token` field on `models.NotificationProvider` carries `json:"-"`, preventing it from being marshalled into any JSON response. Handler-level defense-in-depth also explicitly clears the token before responding in `List`, `Create`, and `Update`:
|
||||
|
||||
```go
|
||||
provider.HasToken = provider.Token != ""
|
||||
provider.Token = ""
|
||||
c.JSON(http.StatusOK, provider)
|
||||
```
|
||||
|
||||
Two independent layers prevent token leakage.
|
||||
|
||||
---
|
||||
|
||||
### 3.2 SSRF Hostname Pin (`api.pushover.net`)
|
||||
|
||||
**Production dispatch path** (`notification_service.go`):
|
||||
```go
|
||||
pushoverBase := s.pushoverAPIBaseURL // always "https://api.pushover.net" in production
|
||||
dispatchURL = pushoverBase + "/1/messages.json"
|
||||
|
||||
parsedURL, parseErr := neturl.Parse(dispatchURL)
|
||||
expectedHost := "api.pushover.net"
|
||||
// test-seam bypass: only applies when pushoverAPIBaseURL has been overridden in tests
|
||||
if parsedURL != nil && parsedURL.Hostname() != "" && pushoverBase != "https://api.pushover.net" {
|
||||
expectedHost = parsedURL.Hostname()
|
||||
}
|
||||
if parseErr != nil || parsedURL.Hostname() != expectedHost {
|
||||
return fmt.Errorf("pushover dispatch URL validation failed: invalid hostname")
|
||||
}
|
||||
```
|
||||
|
||||
**Finding: ✅ SECURE**
|
||||
|
||||
In production, `pushoverAPIBaseURL` is always `"https://api.pushover.net"` (set in `NewNotificationService`). The bypass condition `pushoverBase != "https://api.pushover.net"` is only true in unit tests where the field is overridden via direct struct access (`svc.pushoverAPIBaseURL = server.URL`). This field is:
|
||||
|
||||
- A private Go struct field — cannot be set via any API endpoint
|
||||
- Absent from `notificationProviderUpsertRequest` and `notificationProviderTestRequest`
|
||||
- Identical in design to the existing Telegram SSRF pin (reviewed previously)
|
||||
|
||||
No user-supplied input can influence the dispatch hostname.
|
||||
|
||||
---
|
||||
|
||||
### 3.3 Template Injection — `token`/`user` Field Override
|
||||
|
||||
**Dispatch logic** (`notification_service.go`):
|
||||
```go
|
||||
// Template payload is rendered, then server-side values OVERWRITE any user-supplied keys:
|
||||
jsonPayload["token"] = decryptedToken // from DB
|
||||
jsonPayload["user"] = p.URL // from DB
|
||||
```
|
||||
|
||||
**Finding: ✅ SECURE**
|
||||
|
||||
Server-side values always overwrite any `token` or `user` keys that may have been injected via the provider's Config template. This is explicitly exercised by `TestPushoverDispatch_PayloadInjection`, which confirms that a template containing `"token": "fake-token", "user": "fake-user"` is replaced with the real decrypted DB values before the outbound HTTP request is made.
|
||||
|
||||
---
|
||||
|
||||
### 3.4 Emergency Priority=2 Rejection
|
||||
|
||||
**Validation** (`notification_service.go`):
|
||||
```go
|
||||
if priority, ok := jsonPayload["priority"]; ok {
|
||||
if p, isFloat := priority.(float64); isFloat && p == 2 {
|
||||
return fmt.Errorf("pushover emergency priority (2) requires retry and expire parameters; not yet supported")
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
**Finding: ✅ CORRECT**
|
||||
|
||||
Emergency priority (2) is blocked with a clear, actionable error. JSON numbers are decoded as `float64` by `json.Unmarshal`, so the `p == 2` comparison is type-safe. Non-emergency priorities (-2, -1, 0, 1) pass through. The comparison `float64(2) == 2` evaluates correctly in Go.
|
||||
|
||||
Covered by `TestPushoverDispatch_EmergencyPriorityRejected`.
|
||||
|
||||
---
|
||||
|
||||
### 3.5 Test() Write-Only Guard — Pushover and Telegram
|
||||
|
||||
**Handler** (`notification_provider_handler.go`):
|
||||
```go
|
||||
if providerType == "pushover" && strings.TrimSpace(req.Token) != "" {
|
||||
respondSanitizedProviderError(c, http.StatusBadRequest, "TOKEN_WRITE_ONLY", "validation",
|
||||
"Pushover API token is accepted only on provider create/update")
|
||||
return
|
||||
}
|
||||
|
||||
if providerType == "telegram" && strings.TrimSpace(req.Token) != "" {
|
||||
respondSanitizedProviderError(c, http.StatusBadRequest, "TOKEN_WRITE_ONLY", "validation",
|
||||
"Telegram bot token is accepted only on provider create/update")
|
||||
return
|
||||
}
|
||||
```
|
||||
|
||||
**Finding: ✅ CORRECT**
|
||||
|
||||
Passing a token in the `Test` request body is rejected with HTTP 400 `TOKEN_WRITE_ONLY` for both Pushover and Telegram. The test dispatch always reads credentials from the database (provider ID is required), preventing token exfiltration or injection via the test endpoint. The same guard exists for Gotify and Slack, maintaining symmetry across all token-based providers.
|
||||
|
||||
---
|
||||
|
||||
### 3.6 `pushoverAPIBaseURL` Accessibility via API
|
||||
|
||||
**Finding: ✅ SECURE**
|
||||
|
||||
`pushoverAPIBaseURL` is a private struct field with no API exposure:
|
||||
1. Not exported from the `NotificationService` struct
|
||||
2. Not present in any request struct unmarshalled from user input
|
||||
3. Only modified in test code via `svc.pushoverAPIBaseURL = server.URL`
|
||||
4. Never read from user input, headers, query parameters, or provider Config
|
||||
|
||||
Production dispatches invariably target `https://api.pushover.net/1/messages.json`.
|
||||
|
||||
---
|
||||
|
||||
## 4. Findings
|
||||
|
||||
### FE-001 — Stale Test Assertion After Adding Pushover Provider Type
|
||||
|
||||
**Severity:** 🟡 MEDIUM (test failure, blocks CI)
|
||||
**File:** `frontend/src/components/__tests__/SecurityNotificationSettingsModal.test.tsx:89`
|
||||
**Status:** ✅ **FIXED**
|
||||
|
||||
**Description:** After Pushover was added to `SUPPORTED_NOTIFICATION_PROVIDER_TYPES` in `notifications.ts`, the assertion checking the provider type dropdown options was not updated. The test expected 6 types but the implementation exposes 7, causing the test to fail and block CI.
|
||||
|
||||
**Before:**
|
||||
```typescript
|
||||
expect(Array.from(typeSelect.options).map((option) => option.value))
|
||||
.toEqual(['discord', 'gotify', 'webhook', 'email', 'telegram', 'slack']);
|
||||
```
|
||||
|
||||
**After (applied):**
|
||||
```typescript
|
||||
expect(Array.from(typeSelect.options).map((option) => option.value))
|
||||
.toEqual(['discord', 'gotify', 'webhook', 'email', 'telegram', 'slack', 'pushover']);
|
||||
```
|
||||
|
||||
All 4 tests in `SecurityNotificationSettingsModal.test.tsx` pass after the fix.
|
||||
|
||||
---
|
||||
|
||||
### BE-001 — No Handler-Level Unit Tests for Pushover TOKEN_WRITE_ONLY Guard
|
||||
|
||||
**Severity:** 🟢 LOW (coverage gap, not a functional defect)
|
||||
**File:** `backend/internal/api/handlers/notification_provider_handler_test.go`
|
||||
**Status:** ⚠️ INFORMATIONAL
|
||||
|
||||
**Description:** The `Test()` handler's Pushover `TOKEN_WRITE_ONLY` guard is correctly implemented and is structurally identical to the existing Gotify, Slack, and Telegram guards. The guard is verified at the code-review level but no dedicated handler integration test exercises it. This gap applies to all four token-based providers, not Pushover in isolation.
|
||||
|
||||
**Recommendation:** Add handler integration tests for `TOKEN_WRITE_ONLY` guards across Gotify, Telegram, Slack, and Pushover in a follow-up issue to achieve symmetrical handler coverage.
|
||||
|
||||
---
|
||||
|
||||
### E2E-001 — No Playwright E2E Spec for Pushover Provider
|
||||
|
||||
**Severity:** 🟢 LOW (coverage gap)
|
||||
**Status:** ⚠️ INFORMATIONAL
|
||||
|
||||
**Description:** The implementation scope stated "New E2E spec" but no Playwright `.spec.ts` file for Pushover was found in the repository. The `playwright/` directory contains only the auth fixture. Frontend unit tests (`Notifications.test.tsx`) provide partial coverage of the form rendering path, but there is no browser-level test exercising the full add/edit/test flow for Pushover.
|
||||
|
||||
**Recommendation:** Create a Playwright spec covering: add Pushover provider, verify "User Key" and "API Token (Application)" field labels, test provider response handling. Target the next release cycle.
|
||||
|
||||
---
|
||||
|
||||
### SEC-001 — SSRF Test Bypass Pattern (Design Note)
|
||||
|
||||
**Severity:** ✅ INFORMATIONAL (no action required)
|
||||
|
||||
**Description:** The `pushoverAPIBaseURL` field allows the SSRF pin to be bypassed in test environments. This is intentional, mirrors the existing Telegram test-seam pattern, and is not exploitable via any API vector. Documented for audit trail completeness.
|
||||
|
||||
---
|
||||
|
||||
## 5. Summary
|
||||
|
||||
| Check | Result |
|
||||
|-------|--------|
|
||||
| Backend compilation (`go build ./...`) | ✅ PASS |
|
||||
| Backend unit tests (`go test ./...`) | ✅ PASS |
|
||||
| Backend linting (`make lint-fast`) | ✅ PASS |
|
||||
| Frontend TypeScript (`tsc --noEmit`) | ✅ PASS |
|
||||
| Frontend unit tests (`vitest run`) | ✅ PASS (after FE-001 fix) |
|
||||
| Pre-commit hooks | ⚠️ N/A (project uses Lefthook) |
|
||||
| Trivy filesystem scan | ✅ PASS — 0 vulns, 0 secrets |
|
||||
| Regression — services package | ✅ PASS |
|
||||
| Regression — handlers package | ✅ PASS |
|
||||
| `Token` field `json:"-"` guard | ✅ SECURE |
|
||||
| SSRF hostname pin (`api.pushover.net`) | ✅ SECURE |
|
||||
| Template injection guard | ✅ SECURE |
|
||||
| Emergency priority=2 rejection | ✅ CORRECT |
|
||||
| Test() write-only guard (Pushover + Telegram) | ✅ CORRECT |
|
||||
| `pushoverAPIBaseURL` API inaccessibility | ✅ SECURE |
|
||||
|
||||
**Critical/High security findings: 0**
|
||||
**Total findings: 4** (1 fixed, 3 informational coverage gaps)
|
||||
|
||||
The Pushover notification provider implementation is secure and functionally correct. The one blocking defect (FE-001) was identified and resolved during this audit. The three remaining findings are non-blocking coverage gaps with no security impact and no CVE surface.
|
||||
Reference in New Issue
Block a user